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

[David Ball <[e-mail]>]

Thanks - more inline with [DB2]:


On 24/08/2017 04:26, Qin Wu wrote:
>
> Thank David for follow up comments. See my reply inline below marked 
> with [Qin-1].
>
> *发件人:*David Ball [mailto:[e-mail]]
> *发送时间:*2017年8月23日20:22
> *收件人:*Qin Wu; [e-mail]
> *抄送:*Stephane Litkowski; Kenichi Ogaki; [e-mail]
> *主题:*Re: [L3sm] New Version Notification for 
> draft-wu-l3sm-rfc8049bis-02.txt
>
> 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:
>
>     > 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.
>
>
> [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.
>

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

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

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

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

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

> > 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.
>
>
> [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>
>
> ”
>
>
> 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>
>
> [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.";
>
>         }
>

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

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

[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


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

-- 
David Ball
<[e-mail]>