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

From: Qin Wu <[email-masked]>
Date: Wed, 9 Aug 2017 10:40:39 +0000

Here is the update to draft-wu-l3sm-rfc8049bis-02 based on additional discussion on the list.
https://www.ietf.org/internet-drafts/draft-wu-l3sm-rfc8049bis-02.txt
Thank David for additional comments. Thank Design team to help address these comments.
The main changes include:
1.Clarify the rational of the model in the section 5 based on David's comment.  
2.Add multi-filter and multi-VPN per entry support for VPN policy.  
3.Modify description for svc-input-bandwidth leaf and svc-output- 
Bandwidth leaf to address inconsistency issue with the text in section 6.12.1. 
4. Add text to clarify the way to achieve Per-VPN QoS policy.
5. Remove address-scope-type since there is no common understanding on this.
6. Modify the description of autonomous-system under container “BGP” to address David's comment on AS.

Regarding provider address and mask to the model for the DHCP and DHCP relay cases, talking with design team members,
We believe these parameters are the one requested by Customer to Provider and therefore we keep it in the model.

Regarding Number of BGP sessions, eBGP multihop between loopbacks and other similar issue, The design team agreed that it is not
reasonable to enumerate all the cases this models doesn't support. The current text has been clear about this.

We believe that we have address all the comments. Thanks!

-Qin
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2017年8月9日 18:20
收件人: Qin Wu; Luis Tomotaki; Kenichi Ogaki; Stephane Litkowski
主题: New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt

A new version of I-D, draft-wu-l3sm-rfc8049bis-02.txt has been successfully submitted by Qin Wu and posted to the IETF repository.

Name:		draft-wu-l3sm-rfc8049bis
Revision:	02
Title:		YANG Data Model for L3VPN Service Delivery
Document date:	2017-08-09
Group:		Individual Submission
Pages:		181
URL:            https://www.ietf.org/internet-drafts/draft-wu-l3sm-rfc8049bis-02.txt
Status:         https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/
Htmlized:       https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wu-l3sm-rfc8049bis-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-02

Abstract:
   This document defines a YANG data model that can be used for
   communication between customers and network operators and to deliver
   a Layer 3 provider-provisioned VPN service.  This document is limited
   to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This
   model is intended to be instantiated at the management system to
   deliver the overall service.  It is not a configuration model to be
   used directly on network elements.  This model provides an abstracted
   view of the Layer 3 IP VPN service configuration components.  It will
   be up to the management system to take this model as input and use
   specific configuration models to configure the different network
   elements to deliver the service.  How the configuration of network
   elements is done is out of scope for this document.

   If approved, this document obsoletes RFC 8049.  The changes are a
   series of small fixes to the YANG module, and some clarifications to
   the text.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: David Ball <[email-masked]>
Date: Tue, 15 Aug 2017 13:03:33 +0100

Thanks Qin, I think we are getting close. :)

Here is a new list of issues (some unresolved from before, some new):

 1. In section 6.2.2, based on the previous discussion we can add a
    statement like: "A service with more than one cloud access is
    functionally identical to multiple services each with a single cloud
    access, where the sites that belong to each service in the latter
    case correspond with the authorized sites for each cloud access in
    the former case.  However, defining a single service with multiple
    cloud accesses may be operationally simpler."
 2. In section 6.3, I think we can add a statement like: "Multiple
    locations can be associated with a single site, but a particular
    location cannot be associated with more than one site." (Personally
    I don't see the need for this restriction, but this sentence is
    based on the previous discussion).
 3. Section 6.3.2.2.1: I don't think we concluded on whether or not
    there is a valid use case whereby *only* IPv6 link-local addresses
    are used for the site-network-access IP addressing, and no other
    addresses.  Currently this can't be represented in the model -
    should it be?  If so, then a sixth option for
    address-allocation-type needs to be added, for "link-local-only". 
    Otherwise, we can ignore it.
 4. In section 6.5.1.3, the ambiguous sentence needs to be fixed.
    OLD: "It is similar to having separate sites, but in this case the
    customer wants to share some physical components while maintaining
    strong communication isolation between the affiliates."
    NEW: "It is similar to having separate sites, but in the case of a
    SubVPN, the customer can share some physical components at a single
    location, while maintaining strong communication isolation between
    the affiliates."
 5. In section 6.5.2.2, the text and examples need to be updated to
    account for the changes you made to VPN policies for multi-VPN and
    multi-filter.  Also need to check all other examples in the doc to
    see if similar fixes are needed.
 6. In section 6.11.6, we can add a statement to clarify that other
    parameters are not in scope; e.g. at the bottom of page 87 add:
    "Other OSPF parameters, such as timers, are typically set by the SP
    and communicated to the customer outside the scope of this model."
 7. Similarly in section 6.11.7, at the end of the second paragraph on
    page 89 (beginning "In the case of dual stack"), we can add: "This,
    along with other BGP parameters such as timers, is communicated to
    the customer outside the scope of this model."
 8. Also for BGP, in the previous discussion we agreed that the case of
    eBGP multihop peering between loopbacks could be added as an augment
    to the model if necessary.  However, in section 6.11.7, it says that
    in the case of BGP, 'the "static-address" allocation type for the IP
    connection MUST be used.'  This wouldn't be necessary in the eBGP
    multihop case.  Could we change the sentence to the following?
    'If the site-network-access connection addresses are used for BGP
    peering, the "static-address" allocation type for the IP connection
    MUST be used. Other peering mechanisms are outside the scope of this
    model.'
 9. In section 6.12.2.2, the second paragraph needs to be updated (or
    deleted?) now that you have added the "direction" leaf.
10. In section 6.12.2.2, my question about how to interpret the case
    where end-to-end is true in an asymmetric VPN is still unanswered. 
    You said that target-sites could be used in the
    qos-classification-policy to determine the source and destination
    between which the bandwidth needs to be reserved - that's true, but
    my question is about the case where target-sites is not used.  For
    example, suppose there is a VPN with 3 sites, and at each site the
    qos-classification policy results in a single class, "foo", that
    matches all traffic. Suppose the qos-profile is defined with the
    following values; then what bandwidth should the SP reserve for
    traffic from A to B?  From B to A?  From B to C?  Or should they
    reject the request?
     1. Site A: svc-input-bandwidth = svc-output-bandwidth = 100000000,
        for class "foo" guaranteed-bw-percent = 10, direction = both,
        end-to-end = true
     2. Site B: svc-input-bandwidth = svc-output-bandwidth = 200000000,
        for class "foo" guaranteed-bw-percent = 20, direction = both,
        end-to-end = true
     3. Site C: svc-input-bandwidth = svc-output-bandwidth = 300000000,
        for class "foo" guaranteed-bw-percent = 30, direction = both,
        end-to-end = true
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
12. The value carried in the svc-mtu leaf is now described more clearly,
    but its intended use is still unclear, at least to me. Would
    something like the following be correct?  If not, what is the
    correct expression of how to interpret this leaf?
    "For a given VPN service, the service provider may discard (or for
    IPv4, may fragment) packets that are longer than the smallest
    svc-mtu across all site-network-accesses for all sites in the VPN."
13. In the new filters container, there is a list of filters indexed by
    type (ipv4, ipv6, lan-tag, or vpn-policy-filter-type).  Each filter
    contains a leaf-list of IPv4 prefixes, a leaf-list of ipv6 prefixes
    and a leaf-list of lan-tags.  Is the intent that the contents of the
    filter matches the type?  There is nothing to enforce that currently
    - should there be a "when" statement for each leaf-list, to restrict
    it to only the case where the type is appropriate (e.g. the
    ipv4-lan-prefix leaf-list would have "when ../type = ipv4")?
    I don't really understand what this new filter list achieves over
    having a single filter that could contain a mix of ipv4 prefixes,
    ipv6 prefixes and lan-tags.  What's the advantage of 3 filters each
    containing a single type over one filter containing all three types?
14. As no-one can remember why BFD can only be specified on
    site-network-accesses and not on sites, I suggest allowing both
    options - i.e. move the "oam" container from "grouping
    site-attachment-ip-connection" to "grouping site-routing"; or better
    still, move it to its own grouping, and use that grouping in both
    site-top-level-cfg and site-network-access-top-level-cfg.
15. For the site-network-access connection addressing,
    ip-connection/ipv4/address-allocation-type is optional with no
    default, but ip-connection/ipv6/address-allocation-type has a
    default defined (static-addressing).  This means it's impossible to
    have a site-network-access that only uses IPv4 addressing.  I think
    the default should be deleted in the IPv6 case, so that an IPv4-only
    site-network-access could be represented by simply not setting the
    IPv6 address-allocation-type.

Thanks,

     David

On 09/08/2017 11:40, Qin Wu wrote:
> _______________________________________________
> L3sm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l3sm

-- 
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Mon, 21 Aug 2017 06:47:39 +0000

David,

Thanks for your additional review comments. We plan to address them at the same time as Adrian's document shepherd review.

> 1. In section 6.2.2, based on the previous discussion we can add a statement like: "A

>     service with more than one cloud access is functionally identical to multiple services

>     each with a single cloud access, where the sites that belong to each service in the

>     latter case correspond with the authorized sites for each cloud access in the former

>     case.  However, defining a single service with multiple cloud accesses may be

>     operationally simpler."

This text is benign. We will add it as the last paragraph in section 6.2.2.

> 2. In section 6.3, I think we can add a statement like: "Multiple locations can be associated

>     with a single site, but a particular location cannot be associated with more than one site."

>    (Personally I don't see the need for this restriction, but this sentence is based on the

>      previous discussion).

We will not be making this change (which seems consistent with your view). A location is a description of a physical location, while a site is part of a service (i.e., a CE). There is no reason to prohibit a service having two co-located CEs. And, of course, two different services could have sites at a single location.

> 3. Section 6.3.2.2.1: I don't think we concluded on whether or not there is a valid use

>    case whereby only IPv6 link-local addresses are used for the site-network-access IP

>    addressing, and no other addresses.  Currently this can't be represented in the

>    model - should it be?  If so, then a sixth option for address-allocation-type needs to

>    be added, for "link-local-only".  Otherwise, we can ignore it.

We think this is covered under "static-address".

If a need for a further classification it can be added in the future.

> OLD:

>   It is similar to having separate sites, but in this case the customer wants to

>   share some physical components while maintaining strong communication

>   isolation between the affiliates.

> NEW

>   It is similar to having separate sites, but in the case of a SubVPN, the

>   customer can share some physical components at a single location, while

>   maintaining strong communication isolation between the affiliates.

> END

Change accepted.

> 5. In section 6.5.2.2, the text and examples need to be updated to account

>     for the changes you made to VPN policies for multi-VPN and multi-filter.

>     Also need to check all other examples in the doc to see if similar fixes are

>     needed.

Good catch. Will fix.

> 6. In section 6.11.6, we can add a statement to clarify that other parameters

>   are not in scope; e.g. at the bottom of page 87 add: "Other OSPF parameters,

>   such as timers, are typically set by the SP and communicated to the customer

>   outside the scope of this model."

OK

OLD

   Regarding dual-stack support, the user MAY specify both IPv4 and IPv6

   address families, if both protocols should be routed through OSPF.

   As OSPF uses separate protocol instances for IPv4 and IPv6, the

   management system will need to configure both OSPF version 2 and OSPF

   version 3 on the PE-CE link.

NEW

   Regarding dual-stack support, the user MAY specify both IPv4 and IPv6

   address families, if both protocols should be routed through OSPF.

   As OSPF uses separate protocol instances for IPv4 and IPv6, the

   management system will need to configure both OSPF version 2 and OSPF

   version 3 on the PE-CE link.

   Other OSPF parameters, such as timers, are typically set by the SP and

   communicated to the customer outside the scope of this model.

END

> 7. Similarly in section 6.11.7, at the end of the second paragraph on page 89

>    (beginning "In the case of dual stack"), we can add: "This, along with other

>    BGP parameters such as timers, is communicated to the customer outside

>    the scope of this model."

OK

OLD

   In the case of dual-stack access, the user MAY request BGP routing

   for both IPv4 and IPv6 by specifying both address families.  It will

   be up to the SP and management system to determine how to describe

   the configuration (two BGP sessions, single, multi-session, etc.).

NEW

   In the case of dual-stack access, the user MAY request BGP routing

   for both IPv4 and IPv6 by specifying both address families.  It will

   be up to the SP and management system to determine how to describe

   the configuration (two BGP sessions, single, multi-session, etc.).  This,

   the customer outside the scope of this model.

END

>     eBGP multihop peering between loopbacks could be added as an

>     augment to the model if necessary.  However, in section 6.11.7, it

>     says that in the case of BGP, 'the "static-address" allocation type for

>     the IP connection MUST be used.'  This wouldn't be necessary in the

>     eBGP multihop case.  Could we change the sentence to the following?

>     MUST be used.  Other peering mechanisms are outside the scope of

>     this model.'

OLD

   BGP activation requires the SP to know the address of the customer

   peer.  The "static-address" allocation type for the IP connection

   MUST be used.  An example of a corresponding XML snippet is described

   as follows:

NEW

   BGP activation requires the SP to know the address of the customer

   peer.  If the site-network-access connection addresses are used for

   BGP peering, the "static-address" allocation type for the IP connection

   MUST be used.  Other peering mechanisms are outside the scope of

   this model.  An example of a corresponding XML snippet is described

   as follows:

END

>     deleted?) now that you have added the "direction" leaf.

We don't believe there is anything actually incorrect about the current text.

>      You said that target-sites could be used in the qos-classification-policy

>      to determine the source and destination between which the bandwidth

>      needs to be reserved - that's true, but my question is about the case

>      where target-sites is not used.  For example, suppose there is a VPN

>      with 3 sites, and at each site the qos-classification policy results in a single

>      class, "foo", that matches all traffic.  Suppose the qos-profile is defined

>      with the following values; then what bandwidth should the SP reserve

>      for traffic from A to B?  From B to A?  From B to C?  Or should they reject

>      the request?

>      1. Site A: svc-input-bandwidth = svc-output-bandwidth = 100000000, for

>          class "foo" guaranteed-bw-percent = 10, direction = both, end-to-end

>           = true

>      2. Site B: svc-input-bandwidth = svc-output-bandwidth = 200000000, for

>           class "foo" guaranteed-bw-percent = 20, direction = both, end-to-end

>          = true

>      3. Site C: svc-input-bandwidth = svc-output-bandwidth = 300000000, for

>          class "foo" guaranteed-bw-percent = 30, direction = both, end-to-end

>          = true

Such a service request is quite precise and reflects a flexible service where the amount of traffic from A to B, B to C, etc. could vary. The operator can determine how to support such a service or can choose to not support it.

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

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

> 12. The value carried in the svc-mtu leaf is now described more clearly, but its intended

>     use is still unclear, at least to me.  Would something like the following be correct?  If

>     not, what is the correct expression of how to interpret this leaf?

>    "For a given VPN service, the service provider may discard (or for IPv4, may fragment)

>     packets that are longer than the smallest svc-mtu across all site-network-accesses for

>     all sites in the VPN."

We think that SPs are used to the concept of link MTU. svc-mtu modifies the link MTU for the site-access links within the scope of a particular service. We think that an SP will know exactly how to handle packets that exceed MTU values

> 13. In the new filters container, there is a list of filters indexed by type (ipv4, ipv6,

>     lan-tag, or vpn-policy-filter-type).  Each filter contains a leaf-list of IPv4 prefixes,

>     a leaf-list of ipv6 prefixes and a leaf-list of lan-tags.  Is the intent that the contents

>     of the filter matches the type?  There is nothing to enforce that currently - should

>     there be a "when" statement for each leaf-list, to restrict it to only the case

>     where the type is appropriate (e.g. the ipv4-lan-prefix leaf-list would have

>     "when ../type = ipv4")?

>     I don't really understand what this new filter list achieves over having a single

>     filter that could contain a mix of ipv4 prefixes, ipv6 prefixes and lan-tags.  What's

>     the advantage of 3 filters each containing a single type over one filter containing

>     all three types?

RFC 8049 allowed multiple filters of any one type, but not a mix of filters of different types. That's now fixed.

> 14. As no-one can remember why BFD can only be specified on site-network-accesses

>    and not on sites, I suggest allowing both options - i.e. move the "oam" container from

>    "grouping site-attachment-ip-connection" to "grouping site-routing"; or better still,

>     move it to its own grouping, and use that grouping in both site-top-level-cfg and

>     site-network-access-top-level-cfg.

While this seems to offer a reduction in configuration in some cases while still allowing the detailed configuration, we don't believe there is much of a saving and don't think this change needs to be made.

> 15. For the site-network-access connection addressing, ip-connection/ipv4/address-

>    allocation-type is optional with no default, but ip-connection/ipv6/address-allocation-

>    type has a default defined (static-addressing).  This means it's impossible to have a

>    site-network-access that only uses IPv4 addressing.  I think the default should be

>    deleted in the IPv6 case, so that an IPv4-only site-network-access could be

>    represented by simply not setting the IPv6 address-allocation-type.

Good catch, to get consistent with original RFC8049, I would propose to add the default for ipv4-only site-network-access as well.

Note that we use "feature" for both ipv4 case and ipv6 case.

Thanks for your time and effort.

Qin

-Qin

-----邮件原件-----

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

发送时间: 2017年8月9日 18:20

Revision: 02

Pages:           181

Abstract:

   the text.

The IETF Secretariat

L3sm mailing list

[email-masked]<mailto:[email-masked]>

--

David Ball

<[email-masked]><mailto:[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Mon, 21 Aug 2017 08:39:15 +0000

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

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 22 Aug 2017 19:13:41 +0900

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.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, August 21, 2017 5:39 PM
To: David Ball; [email-masked]
Cc: Stephane Litkowski; Kenichi Ogaki; [email-masked]
Subject: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt

That sounds reasonable.

---

From: David Ball <[email-masked]>
Date: Wed, 23 Aug 2017 12:44:56 +0100

On 21/08/2017 09:39, Qin Wu wrote:
> >     •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
>

Ah yes, I had forgotten that.  Yang doesn't really handle this case - 
the semantics we want are that only the SP (i.e., the server) can modify 
these values, but they still have to respect the constraint embodied in 
the leafref i.e. that the values are not deleted if they are in use.  I 
don't think NACM quite does it, because that is about access control for 
clients, but here it is the server that can change the values.  Having 
said that, adding "nacm:default-deny-write" to 
l3vpn-service/vpn-profiles and everything under it would be a strong 
hint as to the intended behaviour.

     David

-- 
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Wed, 23 Aug 2017 12:47:38 +0100

> 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 configurab…

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.

     David

-- 
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Wed, 23 Aug 2017 13:21:31 +0100

Thanks Qin, I think most of the comments are being addressed.  Some 
responses below, I've snipped out the ones where we have agreement.

On 21/08/2017 07:47, Qin Wu wrote:
> We will not be making this change (which seems consistent with your 
> view). A location is a description of a physical location, while a 
> site is part of a service (i.e., a CE). There is no reason to prohibit 
> a service having two co-located CEs. And, of course, two different 
> services could have sites at a single location.
>

[DB]
Ok - in that case, for clarity, can we make the opposite statement: 
"Multiple locations can be associated with a single site; similarly, a 
particular location can be associated with more than one site."

[Note: I came to the conclusion above based on the previous discussion 
about SubVPN, where you said site-network-accesses in different sites 
couldn't share physical components because different sites would be 
associated with different locations.  If multiple sites are allowed to 
be associated with the same location, then they could also share some 
physical components, right?]

> If a need for a further classification it can be added in the future.

[DB]
Ok

> We don't believe there is anything actually incorrect about the 

[DB]
Ok, in that case I don't understand it. :)  Suppose there is a 
provider-managed connection with a qos-profile, and the direction in the 
qos profile is set to Site-to-WAN.  The second paragraph says: "the 
provider should ensure scheduling according to the requested policy in 
both traffic directions", but the description of the direction says: 
"used to specify the direction which qos profile is applied to".  Since 
the direction is Site-to-WAN in this example, this means the profile 
would only be applied in that direction, not in both directions.  That 
seems to contradict the previous text that says it should be applied in 
both directions?

> We think that SPs are used to the concept of link MTU. svc-mtu 
> modifies the link MTU for the site-access links within the scope of a 
> particular service. We think that an SP will know exactly how to 
> handle packets that exceed MTU values
>

[DB]
Ok, so the intent is that this is just local to the 
site-network-access.  I.e. we could say: "Packets transmitted over the 
site-network-access that are longer than the svc-mtu may be discarded 
(or for IPv4, fragmented)."

> RFC 8049 allowed multiple filters of any one type, but not a mix of 
> filters of different types. That's now fixed.
>

[DB]
Right, I was comparing to the previous version of 8049bis rather than to 
RFC8049 (which I agree did not allow a mix of prefixes and LAN tags).

With the new version, you could have data like this:

<filters>
   <filter>
     <type>lan</type>
<ipv4-lan-prefix>10.0.0.0/24</ipv4-lan-prefix>  // IPv4 prefix specified 
even though type is lan
   </filter>
   <filter>
     <type>ipv4</type>
     <ipv6-lan-prefix>10::0/64</ipv6-lan-prefix>  // IPv6 prefix and lan 
tag specified even though type is ipv4
     <lan-tag>foo</lan-tag>
   </filter>
</filters>

I think the aim could be achieved with a single filter that contains 
leaf-lists for IPv4, Ipv6 and lan tags, i.e.:

container filter {
   leaf-list ipv4-lan-prefix { type inet:ipv4-prefix; }
   leaf-list ipv6-lan-prefix { type inet:ipv6-prefix; }
   leaf-list lan-tag { type string; }
}

This allows full flexibility, i.e. a filter can have zero or more IPv4 
prefixes, zero or more IPv6 prefixes and zero or more LAN tags.

> While this seems to offer a reduction in configuration in some cases 
> while still allowing the detailed configuration, we don't believe 
> there is much of a saving and don't think this change needs to be made.
>

[DB]
Ok.

> Good catch, to get consistent with original RFC8049, I would propose 
> to add the default for ipv4-only site-network-access as well.
>

[DB]
Using "feature" doesn't solve the problem, since that turns IPv4 or IPv6 
on or off for every service.  However, the SP might have some IPv4-only 
services and some IPv6-only services.  So, they need to advertise both 
features, but they also need a way to not specify an IPv6 connection 
address for the IPv4-only services, and to not specify an IPv4 
connection address for the IPv6-only services.
So, I believe the best solution is to delete the default for the 
address-allocation-type in both cases.

     David

>     Regarding provider address and mask to the model for the DHCP and
>     DHCP relay cases, talking with design team members,
>
>     We believe these parameters are the one requested by Customer to
>     Provider and therefore we keep it in the model.
>
>     Regarding Number of BGP sessions, eBGP multihop between loopbacks
>     and other similar issue, The design team agreed that it is not
>
>     reasonable to enumerate all the cases this models doesn't support.
>     The current text has been clear about this.
>
>     发件人: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]]
>
>     发送时间: 2017年8月9日18:20
>
>     A new version of I-D, draft-wu-l3sm-rfc8049bis-02.txt has been
>     successfully submitted by Qin Wu and posted to the IETF repository.
>
>     URL:
>     Htmlized:
>     https://datatracker.ietf.org/doc/html/draft-wu-l3sm-rfc8049bis-02
>
>     Please note that it may take a couple of minutes from the time of
>     submission until the htmlized version and diff are available at
>     tools.ietf.org.
>
>     The IETF Secretariat
>
>     [email-masked] <mailto:[email-masked]>
>
> <[email-masked]> <mailto:[email-masked]>

-- 
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 Aug 2017 00:50:38 +0000

发件人: David Ball [mailto:[email-masked]]
发送时间: 2017年8月23日 19:45
收件人: Qin Wu; [email-masked]
抄送: Stephane Litkowski; Kenichi Ogaki; [email-masked]
主题: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt

That sounds reasonable.

Ah yes, I had forgotten that.  Yang doesn't really handle this case - the semantics we want are that only the SP (i.e., the server) can modify these values, but they still have to respect the constraint embodied in the leafref i.e. that the values are not deleted if they are in use.  I don't think NACM quite does it, because that is about access control for clients, but here it is the server that can change the values.  Having said that, adding "nacm:default-deny-write" to l3vpn-service/vpn-profiles and everything under it would be a strong hint as to the intended behaviour.

    David

[Qin]: Okay, the propose change will look like this:
“
import ietf-netconf-acm {
  prefix nacm;
}
……
grouping vpn-profile-cfg {
  container valid-provider-identifiers {
   list cloud-identifier {
    if-feature cloud-access;
    key id;
    leaf id {
     type string;
     description
      "Identification of cloud service.
       Local administration meaning.";
    }
    nacm:default-deny-write;
    description
    "List for Cloud Identifiers.";
  }
   list encryption-profile-identifier {
    key id;
    leaf id {
     type string;
     description
      "Identification of the SP encryption profile
       to be used. Local administration meaning.";
    }
    nacm:default-deny-write;
    description
    "List for encryption profile identifiers.";
   }
   list qos-profile-identifier {
    key id;
    leaf id {
     type string;
     description
      "Identification of the QoS Profile to be used.
       Local administration meaning.";
   }
         nacm:default-deny-write;
    description
    "List for QoS Profile Identifiers.";
   }

   list bfd-profile-identifier {
    key id;
    leaf id {
     type string;
     description
      "Identification of the SP BFD Profile to be used.
       Local administration meaning.";
    }
         nacm:default-deny-write;
    description
    "List for BFD profile Identifiers.";
   }
     description
    "Container for Valid Provider Identifies.";
  }
   description
   "Grouping for VPN Profile configuration.";
}
”
This will get in line with Jan’s proposal as well.

--

David Ball

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 Aug 2017 03:26:48 +0000

Thank David for follow up comments. See my reply inline below marked with [Qin-1].
发送时间: 2017年8月23日 20:22

Thanks Qin, I think most of the comments are being addressed.  Some responses below, I've snipped out the ones where we have agreement.

[DB]
Ok - in that case, for clarity, can we make the opposite statement: "Multiple locations can be associated with a single site; similarly, a particular location can be associated with more than one site."

[Qin-1]:The statement we like to put is: Each site is associated with one location or more locations.

[Note: I came to the conclusion above based on the previous discussion about SubVPN, where you said site-network-accesses in different sites couldn't share physical components because different sites would be associated with different locations.  If multiple sites are allowed to be associated with the same location, then they could also share some physical components, right?]

[Qin]: Sure, you can use " same-bearer " attribute to express that constraint the relationship between source site-network-access and target site-network-access.

[DB]
Ok, in that case I don't understand it. :)  Suppose there is a provider-managed connection with a qos-profile, and the direction in the qos profile is set to Site-to-WAN.  The second paragraph says: "the provider should ensure scheduling according to the requested policy in both traffic directions", but the description of the direction says: "used to specify the direction which qos profile is applied to".  Since the direction is Site-to-WAN in this example, this means the profile would only be applied in that direction, not in both directions.  That seems to contradict the previous text that says it should be applied in both directions?

[Qin-1]: I see your point. I think in case of provider-managed or co-managed connection, QoS profile are applied to both direction based on the second paragraph of section 6.12.2.2, that means the parameter “direction” is set to “both”.
In case of customer-managed connection, QoS profile is applied to the direction from SP network to the customer site, that means the parameter “direction” should be set to “WAN-to-Site”.
That’ why we think there is actually incorrect about the current text. Note that “direction” is just optional parameter in this model.

On the other hand, if we want to enhance the current text, we might consider:

1.       allow direction at network access level to override the parameter in the site level.

2.       Use “direction” condition to replace “provider-managed, co-managed, customer-managed” condition in the text and allow more flexibility to apply QoS profile to appropriate traffic direction.
But I like to talk to the design team for this first.

[DB]
Ok, so the intent is that this is just local to the site-network-access.  I.e. we could say: "Packets transmitted over the site-network-access that are longer than the svc-mtu may be discarded (or for IPv4, fragmented)."

[Qin-1]: I would prefer to leave this up to SP to determine how to deal with MTU exceeding, we can not limited only to discard or fragmented, does this make sense?

[DB]
Right, I was comparing to the previous version of 8049bis rather than to RFC8049 (which I agree did not allow a mix of prefixes and LAN tags).

[Qin-1]With the old version of RFC8049, you still can have a mix of prefixes and LAN tags, with two entries instead of single entry
“
      <entries>
       <id>ENTRY1</id>
       <filter>
        <lan-tag>LAN1</lan-tag>
       </filter>
       <vpn>
        <vpn-id>VPN2</vpn-id>
        <site-role>hub-role</site-role>
       </vpn>
      </entries>
      <entries>
       <id>ENTRY2</id>
       <filter>
        <ipv4-lan-prefix>LAN2</ipv4-lan-prefix>
       </filter>
       <vpn>
        <vpn-id>VPN2</vpn-id>
        <site-role>any-to-any-role</site-role>
       </vpn>
      </entries>
”

<filters>
  <filter>
    <type>lan</type>
    <ipv4-lan-prefix>10.0.0.0/24</ipv4-lan-prefix>  // IPv4 prefix specified even though type is lan
  </filter>
  <filter>
    <type>ipv4</type>
    <ipv6-lan-prefix>10::0/64</ipv6-lan-prefix>  // IPv6 prefix and lan tag specified even though type is ipv4
    <lan-tag>foo</lan-tag>
  </filter>
</filters>

[Qin-1]: This can be easily fixed by add when statement, e.g.,
when "derived-from-or-self(../type, 'l3vpn-svc:ipv4')" {
         description
         "Only applies when vpn policy filter is ipv4-lan-prefix.";
        }

I think the aim could be achieved with a single filter that contains leaf-lists for IPv4, Ipv6 and lan tags, i.e.:

container filter {

This allows full flexibility, i.e. a filter can have zero or more IPv4 prefixes, zero or more IPv6 prefixes and zero or more LAN tags.

[Qin]: Similar to our design team's proposal in the new version, but ipv4 and ipv6 and lan-tag are not of the same type. put them in the same container seems weird,☺.
Our proposal follow similar construct proposed for " routing-protocol " list in this model.

[DB]
Using "feature" doesn't solve the problem, since that turns IPv4 or IPv6 on or off for every service.  However, the SP might have some IPv4-only services and some IPv6-only services.  So, they need to advertise both features, but they also need a way to not specify an IPv6 connection address for the IPv4-only services, and to not specify an IPv4 connection address for the IPv6-only services.
So, I believe the best solution is to delete the default for the address-allocation-type in both cases.

[Qin-1]: I am fine to delete both default values, but
RFC7950 section 7.6.1 said:
"
   Note that if the leaf or any of its ancestors has a "when" condition
   or "if-feature" expression that evaluates to "false", then the
   default value is not in use.
"
To my understanding, if the server doesn’t support one feature or advertise one feature, the default value will not in use.
If the server advertise both features, it doesn’t say default value for each feature MUST be specified.
So if both features can be supported, is there any reason we only specify only IPv6 connection or IPv4 connection?

    David

Qin

-Qin

-----邮件原件-----

发送时间: 2017年8月9日 18:20

Revision: 02

Pages:           181

Abstract:

   the text.

The IETF Secretariat

L3sm mailing list

--

David Ball

--

David Ball

---

From: David Ball <[email-masked]>
Date: Thu, 24 Aug 2017 10:32:26 +0100

> This will get in line with Jan’s proposal as well.

If my understanding of RFC 6536 is correct, you need to put it on the 
leaves as well as the lists (it doesn't cascade down the tree like most 
other yang constructs).

     David

-- 
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Thu, 24 Aug 2017 10:52:27 +0100

Thanks - more inline with [DB2]:

On 24/08/2017 04:26, Qin Wu wrote:
> *发件人:*David Ball [mailto:[email-masked]]
> *发送时间:*2017年8月23日20:22
> *收件人:*Qin Wu; [email-masked]
> *抄送:*Stephane Litkowski; Kenichi Ogaki; [email-masked]
> *主题:*Re: [L3sm] New Version Notification for 
> draft-wu-l3sm-rfc8049bis-02.txt
>
>     We will not be making this change (which seems consistent with
>     your view). A location is a description of a physical location,
>     while a site is part of a service (i.e., a CE). There is no reason
>     to prohibit a service having two co-located CEs. And, of course,
>     two different services could have sites at a single location.
>
>
> [DB]

[DB2] I think we already say that; but it is the converse I would like 
to add, i.e. each location can have one or more sites.

> [Qin]: Sure, you can use " same-bearer" attribute to express that 
> constraint the relationship between source site-network-access and 
> target site-network-access.
>
>
>
> provider-managed connection with a qos-profile, and the direction in 
> the qos profile is set to Site-to-WAN.  The second paragraph says: 
> "the provider should ensure scheduling according to the requested 
> policy in both traffic directions", but the description of the 
> direction says: "used to specify the direction which qos profile is 
> applied to".  Since the direction is Site-to-WAN in this example, this 
> means the profile would only be applied in that direction, not in both 
> directions.  That seems to contradict the previous text that says it 
> should be applied in both directions?
>
> [Qin-1]: I see your point. I think in case of provider-managed or 
> co-managed connection, QoS profile are applied to both direction based 
> on the second paragraph of section 6.12.2.2, that means the parameter 
> “direction” is set to “both”.
>
> In case of customer-managed connection, QoS profile is applied to the 
> direction from SP network to the customer site, that means the 
> parameter “direction” should be set to “WAN-to-Site”.
>
> That’ why we think there is actually incorrect about the current text. 
> Note that “direction” is just optional parameter in this model.
>
> 1.allow direction at network access level to override the parameter in 
> the site level.
>
> 2.Use “direction” condition to replace “provider-managed, co-managed, 
> customer-managed” condition in the text and allow more flexibility to 
> apply QoS profile to appropriate traffic direction.
>

[DB2] Ok - option 2 would be my preference but lets see what others think.

> [Qin-1]: I would prefer to leave this up to SP to determine how to 
> deal with MTU exceeding, we can not limited only to discard or 
> fragmented, does this make sense?
>

[DB2] Yes - that is why I said "may be discarded" instead of "must be 
discarded".  With my suggested text, it is still up to SP to determine 
how to handle it, but we are providing some warning for the customer.

> Right, I was comparing to the previous version of 8049bis rather than 
> to RFC8049 (which I agree did not allow a mix of prefixes and LAN tags).
>
> [Qin-1]With the old version of RFC8049, you still can have a mix of 
> prefixes and LAN tags, with two entries instead of single entry
>
> “
>
>       <entries>
>
>        <id>ENTRY1</id>
>
>        <filter>
>
>         <lan-tag>LAN1</lan-tag>
>
>        </filter>
>
>        <vpn>
>
>         <vpn-id>VPN2</vpn-id>
>

[DB2] Yes, adding 'when' statements would also work.

> [Qin]: Similar to our design team's proposal in the new version, but 
> ipv4 and ipv6 and lan-tag are not of the same type. put them in the 
> same container seems weird,J.
>
> Our proposal follow similar construct proposed for " routing-protocol" 
> list in this model.
>
> Using "feature" doesn't solve the problem, since that turns IPv4 or 
> IPv6 on or off for every service.  However, the SP might have some 
> IPv4-only services and some IPv6-only services.  So, they need to 
> advertise both features, but they also need a way to not specify an 
> IPv6 connection address for the IPv4-only services, and to not specify 
> an IPv4 connection address for the IPv6-only services.
> To my understanding, if the server doesn’t support one feature or 
> advertise one feature, the default value will not in use.
>
> So if both features can be supported, is there any reason we only 
> specify only IPv6 connection or IPv4 connection?
>

[DB2] The difference is that features apply across the whole server - if 
the ipv4 feature is disabled, then the server cannot support IPv4 at 
all, and there can be *no* services with IPv4.  However, the case I was 
describing is different - in this case, there are some services that 
support IPv4 and some that do not.  For example, the SP might offer an 
IPv4 product, and IPv6 product and a dual-stack product, where the 
dual-stack product is more expensive.  So some customers might choose 
IPv4-only or IPv6-only - or a particular customer might choose a mix of 
ipv4-only and ipv6-only services.  This is why I think the default 
should be deleted in both cases.

     David

>     6. Modify the description of autonomous-system under container “BGP”to address David's comment on AS.
>

-- 
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 Aug 2017 10:11:12 +0000

发送时间: 2017年8月24日 17:32

If my understanding of RFC 6536 is correct, you need to put it on the leaves as well as the lists (it doesn't cascade down the tree like most other yang constructs).

[Qin]: ahha, I find a example on how to use “nacm:default-deny-write;”, see example in RFC7317,
So we only need to put it on container level, the change will be like this:
“

Does this work for you?

    David

--

David Ball

---

From: David Ball <[email-masked]>
Date: Thu, 24 Aug 2017 11:30:40 +0100

On 24/08/2017 11:11, Qin Wu wrote:
> *发送时间:*2017年8月24日17:32
> leaves as well as the lists (it doesn't cascade down the tree like 
> most other yang constructs).
>
> [Qin]: ahha, I find a example on how to use 
> “nacm:default-deny-write;”, see example in RFC7317,
>

[DB] Like I said, my reading of RFC6536 is that it doesn't cascade down 
the tree, so it needs to be put on every node.  Just putting it on the 
container would mean that the client couldn't create the container, but 
if the container already existed, they would still be able to write to 
everything inside it.  See RFC6536 section 3.2.3 for example.  I think 
the example in RFC7317 is wrong, although it is the same authors as 
RFC6536, which is curious.  I'll check with Martin.

     David

-- 
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 Aug 2017 10:50:48 +0000

发件人: L3sm [mailto:[email-masked]] 代表 David Ball
发送时间: 2017年8月24日 18:31
收件人: Qin Wu; [email-masked]
抄送: Stephane Litkowski; Kenichi Ogaki; [email-masked]
主题: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt

发件人: David Ball [mailto:[email-masked]]
发送时间: 2017年8月24日 17:32
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Stephane Litkowski; Kenichi Ogaki; [email-masked]<mailto:[email-masked]>
主题: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt

[DB] Like I said, my reading of RFC6536 is that it doesn't cascade down the tree, so it needs to be put on every node.  Just putting it on the container would mean that the client couldn't create the container, but if the container already existed, they would still be able to write to everything inside it.  See RFC6536 section 3.2.3 for example.  I think the example in RFC7317 is wrong, although it is the same authors as RFC6536, which is curious.  I'll check with Martin.

[Qin]:  Yes, we need to get confirm about this, it looks to me if we apply “nacm:default-deny-write” to top level node, “nacm:default-deny-write” applicability will spread to the lower level nodes as well.
By reading RFC6536 section 3.2.3 example, I didn’t get the same understanding. Please correct me if I am wrong.

    David

“

    David

--

David Ball

--

David Ball

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 Aug 2017 11:11:32 +0000

-----邮件原件-----
发件人: David Ball [mailto:[email-masked]] 
发送时间: 2017年8月23日 19:48
收件人: Ogaki, Kenichi; Qin Wu; [email-masked]
抄送: 'Stephane Litkowski'; [email-masked]
主题: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt

> 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 configurab…

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

>>      • 
>> l3vpn-service/sites/site/site-network-accesses/site-network-access/ip
>> -connection/ipv6/addresses/mask
>   
>
> That sounds reasonable.
>

--
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Thu, 24 Aug 2017 13:28:56 +0100

On 24/08/2017 11:50, Qin Wu wrote:
>
> [DB] Like I said, my reading of RFC6536 is that it doesn't cascade 
> down the tree, so it needs to be put on every node.  Just putting it 
> on the container would mean that the client couldn't create the 
> container, but if the container already existed, they would still be 
> able to write to everything inside it.  See RFC6536 section 3.2.3 for 
> example.  I think the example in RFC7317 is wrong, although it is the 
> same authors as RFC6536, which is curious.  I'll check with Martin.
>
> [Qin]:  Yes, we need to get confirm about this, it looks to me if we 
> apply “nacm:default-deny-write” to top level node, 
> “nacm:default-deny-write” applicability will spread to the lower level 
> nodes as well.
>
> By reading RFC6536 section 3.2.3 example, I didn’t get the same 
> understanding. Please correct me if I am wrong.
>

I got a reply from Martin, he says you are right (although he agreed 
RFC6536 is unclear).  So, it's only needed on the container.

Thanks,

     David

-- 
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 Aug 2017 13:54:05 +0000

Thanks David, I am on netconf list.:-)

Sent from HUAWEI AnyOffice
发件人： daviball
收件人： Qin Wu; l3sm;
抄送： stephane.litkowski; ke-oogaki; adrian;
主题： Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
时间： 2017-08-24 20:29:08

I got a reply from Martin, he says you are right (although he agreed RFC6536 is unclear).  So, it's only needed on the container.

Thanks,

    David

---

From: Qin Wu <[email-masked]>
Date: Fri, 25 Aug 2017 06:18:17 +0000

发送时间: 2017年8月24日 17:52

[DB]

[DB2] I think we already say that; but it is the converse I would like to add, i.e. each location can have one or more sites.

[Qin-2]:I think the text MUST be consistent with the model. In the model, the site and location are organized as:
One site can have one or more location. Not the other way around, in the text, we can see multi-location site is one typical example that is discussed in the draft.
 “
      +--rw sites
        +--rw site* [site-id]
         +--rw site-id         svc-id
         +--rw requested-site-start?  yang:date-and-time
         +--rw requested-site-stop?   yang:date-and-time
         +--rw locations
         | +--rw location* [location-id]
”
Considering consistency and clarity, I think we should use statement I mentioned above previously.
[Note: I came to the conclusion above based on the previous discussion about SubVPN, where you said site-network-accesses in different sites couldn't share physical components because different sites would be associated with different locations.  If multiple sites are allowed to be associated with the same location, then they could also share some physical components, right?]

[DB]

[Qin-2]:ok, I have asked design team to express on the list if they have different opinion.

[DB]

[DB2] Yes - that is why I said "may be discarded" instead of "must be discarded".  With my suggested text, it is still up to SP to determine how to handle it, but we are providing some warning for the customer.

[Qin-2]:I still feel this model is just a service model which is not directly code implemented on the network device to control the network operation. I am reluctant to add this lower layer constraint to the service parameter in the service model. SP may instruct the management system to provision the network device with appropriate policy.

[DB]

<filters>
  <filter>
    <type>lan</type>

[Qin-2]: Thanks.

container filter {

[DB]

[DB2] The difference is that features apply across the whole server - if the ipv4 feature is disabled, then the server cannot support IPv4 at all, and there can be no services with IPv4.  However, the case I was describing is different - in this case, there are some services that support IPv4 and some that do not.  For example, the SP might offer an IPv4 product, and IPv6 product and a dual-stack product, where the dual-stack product is more expensive.  So some customers might choose IPv4-only or IPv6-only - or a particular customer might choose a mix of ipv4-only and ipv6-only services.  This is why I think the default should be deleted in both cases.

[Qin-2]:Sounds reasonable to me, I will delete default if there is no one against it.
    David

    David

Qin

-Qin

-----邮件原件-----

发送时间: 2017年8月9日 18:20

Revision: 02

Pages:           181

Abstract:

   the text.

The IETF Secretariat

L3sm mailing list

--

David Ball

--

David Ball

--

David Ball

---

From: David Ball <[email-masked]>
Date: Fri, 25 Aug 2017 11:53:41 +0100

Thanks - a couple more comments inline with [DB3]:

On 25/08/2017 07:18, Qin Wu wrote:
>
> *发件人:*L3sm [mailto:[email-masked]] *代表 *David Ball
> *发送时间:*2017年8月24日17:52
>     *收件人:*Qin Wu; [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     Thanks Qin, I think most of the comments are being addressed. 
>     Some responses below, I've snipped out the ones where we have
>     agreement.
>
>         locations can be associated
>
>         your view). A location is a description of a physical
>         location, while a site is part of a service (i.e., a CE).
>         There is no reason to prohibit a service having two co-located
>         CEs. And, of course, two different services could have sites
>         at a single location.
>
>
>     [DB]
>     Ok - in that case, for clarity, can we make the opposite
>     statement: "Multiple locations can be associated with a single
>     site; similarly, a particular location can be associated with more
>     than one site."
>
>
> [Qin-2]:I think the text MUST be consistent with the model. In the 
> model, the site and location are organized as:
>
> One site can have one or more location. Not the other way around, in 
> the text, we can see multi-location site is one typical example that 
> is discussed in the draft.
>
> “
>
> +--rw sites
>
> +--rw site* [site-id]
>
> +--rw site-id         svc-id
>

[DB3]
Ok, but I think that's just a phrasing issue.  Would you be happier 
adding "Two or more sites can be associated with the same location, by 
referencing the same location ID"?

> [Qin-2]:I still feel this model is just a service model which is not 
> directly code implemented on the network device to control the network 
> operation. I am reluctant to add this lower layer constraint to the 
> service parameter in the service model. SP may instruct the management 
> system to provision the network device with appropriate policy.
>

[DB3] I completely agree; my point is to provide some information to the 
customer about how the service might behave if they request a particular 
value for the MTU.

     David

> [DB2] The difference is that features apply across the whole server - 
> if the ipv4 feature is disabled, then the server cannot support IPv4 
> at all, and there can be *no* services with IPv4.  However, the case I 
> was describing is different - in this case, there are some services 
> that support IPv4 and some that do not.  For example, the SP might 
> offer an IPv4 product, and IPv6 product and a dual-stack product, 
> where the dual-stack product is more expensive.  So some customers 
> might choose IPv4-only or IPv6-only - or a particular customer might 
> choose a mix of ipv4-only and ipv6-only services.  This is why I think 
> the default should be deleted in both cases.
>

-- 
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Fri, 25 Aug 2017 12:03:53 +0100

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.

Thanks,

     David

-- 
David Ball
<[email-masked]>

---

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Fri, 25 Aug 2017 11:17:37 +0000

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

-----邮件原件-----
发件人: David Ball [mailto:[email-masked]]
发送时间: 2017年8月23日 19:48
收件人: Ogaki, Kenichi; Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: 'Stephane Litkowski'; [email-masked]<mailto:[email-masked]>
主题: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt

Hi Qin,

     David

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, August 21, 2017 5:39 PM
To: David Ball; [email-masked]
Cc: Stephane Litkowski; Kenichi Ogaki; [email-masked]
Subject: Re: [L3sm] New Version Notification for

That sounds reasonable.

--
David Ball
<[email-masked]>

--
David Ball
<[email-masked]<mailto:[email-masked]>>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 25 Aug 2017 12:59:42 +0000

Hi David

See comment inline, please.

Thanks,
Kenichi

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 28 Aug 2017 10:13:47 +0000

发送时间: 2017年8月25日 18:54

[DB]

[DB3]
Ok, but I think that's just a phrasing issue.  Would you be happier adding "Two or more sites can be associated with the same location, by referencing the same location ID"?

[Qin-3]:Sounds good to me. I will see how to add this.

[DB]

[DB]

[DB3] I completely agree; my point is to provide some information to the customer about how the service might behave if they request a particular value for the MTU.

[Qin-3]: I prefer to keep as it does, but if you insist, we can consider to add something like this:
“
if the requested svc-mtu cannot be fulfilled, the
management system should return a error message indicating the fulfillment is not possible.  How this SHOULD be communicated by the SP to the customer via a mechanism that is out of scope for this document.
”

    David

---

From: David Ball <[email-masked]>
Date: Wed, 30 Aug 2017 12:09:16 +0100

Hi Qin,

On 28/08/2017 11:13, Qin Wu wrote:
>
> [DB3] I completely agree; my point is to provide some information to 
> the customer about how the service might behave if they request a 
> particular value for the MTU.
>
> “if the requested svc-mtu cannot be fulfilled, the management system 
> should return a error message indicating the fulfillment is not 
> possible.  How this SHOULD be communicated by the SP to the customer 
> via a mechanism that is out of scope for this document.”
>

This doesn't really address my point.  What does it mean for the 
requested svc-mtu to be fulfilled?  What behaviour is the customer 
actually requesting by setting this leaf to a particular value?

     David

-- 
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Wed, 30 Aug 2017 12:19:12 +0100

Hi Kenichi,

> [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…

[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
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Wed, 30 Aug 2017 12:32:14 +0000

It means the requested svc-MTU exceeds MTU limit set by the network, the management system may trigger some MTU discovery mechanism to check this.

时间： 2017-08-30 19:09:33

Hi Qin,

[Qin-3]: I prefer to keep as it does, but if you insist, we can consider to add something like this:
“if the requested svc-mtu cannot be fulfilled, the management system should return a error message indicating the fulfillment is not possible.  How this SHOULD be communicated by the SP to the customer via a mechanism that is out of scope for this document.”

This doesn't really address my point.  What does it mean for the requested svc-mtu to be fulfilled?  What behaviour is the customer actually requesting by setting this leaf to a particular value?

    David

---

From: David Ball <[email-masked]>
Date: Wed, 30 Aug 2017 15:28:14 +0100

Right, but that would still be true if the leaf was called 
svc-flagglestops and there was a flagglestop limit set by the network.  :)

My question is what specific behaviour is the customer requesting or 
expecting by setting svc-mtu to a specific value? Assuming the SP 
accepts the request, there is presumably some resulting difference in 
behaviour for packets shorter than the requested value vs packets longer 
than the requested value?  If so, what is it?  For instance, is it that 
packets with length <= svc-mtu will not be discarded due to their 
length, whereas packets with length > svc-mtu might be?

Right now, the draft does not say anything about the meaning of the 
svc-mtu leaf - one can infer from the name of the leaf that it has 
something to do with packet length, but the details are not specified.  
As Jan said: "For a standard to be useful/interoperable, the system 
behavior needs to be predictable. Undefined behavior needs to become 
defined or outlawed.".  There is no behaviour defined for the svc-mtu 
leaf currently - that is the problem I would like to see addressed.

     David

On 30/08/2017 13:32, Qin Wu wrote:
> *发件人： *daviball
> *收件人： *Qin Wu; l3sm;
> *抄送： *stephane.litkowski; ke-oogaki; adrian;
> *主题： *Re: [L3sm] New Version Notification for 
> *时间： *2017-08-30 19:09:33
>
>
> Hi Qin,
>

-- 
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Wed, 30 Aug 2017 15:03:14 +0000

What customer cares about is whether a service parameter can be enforced or used to create a service successfully, why he has to care about how operator use this parameter to control or operate the network or whether specific range should or should not be discarded,isn't this up to SP to implement this details?!
The earlier proposal is just to specify such behavior from customer perspective.

Sent from HUAWEI AnyOffice
发件人： daviball
收件人： Qin Wu; l3sm;
抄送： stephane.litkowski; ke-oogaki; adrian;
主题： Re: 答复: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
时间： 2017-08-30 22:28:28

Right, but that would still be true if the leaf was called svc-flagglestops and there was a flagglestop limit set by the network.  :)

My question is what specific behaviour is the customer requesting or expecting by setting svc-mtu to a specific value?  Assuming the SP accepts the request, there is presumably some resulting difference in behaviour for packets shorter than the requested value vs packets longer than the requested value?  If so, what is it?  For instance, is it that packets with length <= svc-mtu will not be discarded due to their length, whereas packets with length > svc-mtu might be?

Right now, the draft does not say anything about the meaning of the svc-mtu leaf - one can infer from the name of the leaf that it has something to do with packet length, but the details are not specified.  As Jan said: "For a standard to be useful/interoperable, the system behavior needs to be predictable. Undefined behavior needs to become defined or outlawed.".  There is no behaviour defined for the svc-mtu leaf currently - that is the problem I would like to see addressed.

    David

Hi Qin,

    David

---

From: David Ball <[email-masked]>
Date: Wed, 30 Aug 2017 17:54:15 +0100

On 30/08/2017 16:03, Qin Wu wrote:
> What customer cares about is whether a service parameter can be enforced or used to create a service successfully,

Agreed.  How can this be done if the customer does not know what the 
parameter means?

>  why he has to care about how operator use this parameter to control or operate the network 
> or whether specific range should or should not be discarded,isn't this up to SP to implement this details?!

He doesn't care about whether a specific range should or shouldn't be 
discarded, but he does want to know that the packets he cares about are 
guaranteed not to be discarded.  That is presumably why he would pick a 
particular value for the svc-mtu.  For example, if the customer requests 
svc-mtu to 9000, that presumably means that they want to be sure that 
packets of size up to 9000 will not be discarded.  (Of course, if SP 
can't support that, they will reject the request).  OTOH if the customer 
requests 1400, that presumably means they don't care about packets 
bigger than that (but even so, the SP might still pass packets of length 
9000).

> The earlier proposal is just to specify such behavior from customer perspective.

I didn't see that.  The last proposal just said that if the SP can't 
fulfil the request then they can reject it, which is true for all 
leaves; it didn't say anything about what "svc-mtu" means to the 
customer.  There is nothing in the draft that relates the leaf called 
"svc-mtu" to the length of packets or the behaviour of the service.

     David

> *主题： *Re: 答复: [L3sm] New Version Notification for 
> *时间： *2017-08-30 22:28:28
>
>
> behaviour for packets shorter than the requested value vs packets 
> longer than the requested value?  If so, what is it?  For instance, is 
> it that packets with length <= svc-mtu will not be discarded due to 
> their length, whereas packets with length > svc-mtu might be?
>
> something to do with packet length, but the details are not 
> specified.  As Jan said: "For a standard to be useful/interoperable, 
> the system behavior needs to be predictable. Undefined behavior needs 
> to become defined or outlawed.".  There is no behaviour defined for 
> the svc-mtu leaf currently - that is the problem I would like to see 
> addressed.
>
>
>     David
>
>

-- 
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Thu, 31 Aug 2017 01:51:22 +0000

We spin on this issue for quite a while, ☺, please see my reply below.

发件人: David Ball [mailto:[email-masked]]
发送时间: 2017年8月31日 0:54
收件人: Qin Wu; l3sm
抄送: stephane.litkowski; ke-oogaki; adrian
主题: Re: [L3sm] 答复: 答复: New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt

Agreed.  How can this be done if the customer does not know what the parameter means?

[Qin]: See below.
 why he has to care about how operator use this parameter to control or operate the network or whether specific range should or should not be discarded,isn't this up to SP to implement this details?!

He doesn't care about whether a specific range should or shouldn't be discarded, but he does want to know that the packets he cares about are guaranteed not to be discarded.

[Qin]: We are using different language or term to describe similar thing, e.g.,the service is guaranteed in your saying means the parameters can be enforced the service can be fulfilled in my saying.

That is presumably why he would pick a particular value for the svc-mtu.  For example, if the customer requests svc-mtu to 9000, that presumably means that they want to be sure that packets of size up to 9000 will not be discarded.  (Of course, if SP can't

support that, they will reject the request).  OTOH if the customer requests 1400, that presumably means they don't care about packets bigger than that (but even so, the SP might still pass packets of length 9000).

I didn't see that.  The last proposal just said that if the SP can't fulfil the request then they can reject it, which is true for all leaves; it didn't say anything about what "svc-mtu" means to the customer.

[Qin]:RFC8049 clearly says "If CsC is enabled, the requested "svc-mtu" leaf will refer to the
   MPLS MTU and not to the IP MTU. ".

”

There is nothing in the draft that relates the leaf called "svc-mtu" to the length of packets or the behaviour of the service.

[Qin]: The service level svc-mtu parameter will be translated into orchestrated configuration parameter such as path MTU, I think svc-mtu is linking to end to end MTU or path MTU, It is possible for the path MTU to be configured manually or to be discovered dynamically. Path MTU is linking to packet length, the size of any packet in the traffic flow should not exceed svc-mtu value, or
svc-mtu should not exceed path MTU or end to end MTU, otherwise the service will not be enforced or guaranteed.
We also have interface MTU for each network device along the path, but this is not service-level parameter, it is set at each hop along the path. Fragmentation or packet drop, silent or not, may occur on hops along the route where a interface MTU is smaller than the size of the datagram.

    David

    David

Hi Qin,

    David

--

David Ball

--

David Ball

L3sm mailing list

--

David Ball