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

[Qin Wu <[e-mail]>]

David,

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

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



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.



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

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

   along with other BGP parameters such as timers, is communicated to

   the customer outside the scope of this model.

END



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



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



> 9. In section 6.12.2.2, the second paragraph needs to be updated (or

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



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



> 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



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)

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



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

https://www.ietf.org/mailman/listinfo/l3sm



--

David Ball

<[e-mail]><mailto:[e-mail]>