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

[David Ball <[e-mail]>]

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:
> 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
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]]
> 发送时间: 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
>
> _______________________________________________
> L3sm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/l3sm

-- 
David Ball
<[e-mail]>