Re: [L3sm] Next Step of RFC8049

[David Ball <[e-mail]>]

Hi Qin,

As you are working on a bis version, I have a few questions on RFC8049 
that might lead to discussion on the list, and perhaps some further changes.

 1. The scope of the RFC seems to be focused on information that needs
    to be passed from the customer to the SP (e.g. in a "request");
    however, clearly for the customer to be able to use the service,
    there is also information that needs to be passed back from the SP
    to the customer.  It seems that the model is not intended to cover
    that - is that right?  I think that's fine, but it would be helpful
    to make this clearer (perhaps in section 5?)
 2. I have some questions about the concept of a "site".  In the
    simplest case, it seems clear that this means a single physical
    location, with one or more connections (site network accesses) to
    the SP.  The RFC also describes a case where a single "site" could
    be in multiple locations that are interconnected independently of
    the VPN service - the example given is multiple offices in the same
    city.  Does this extend more generally? E.g., if two locations in
    different cities are connected by a backdoor link, does that mean
    they're the same site?  What about if the backdoor link is only used
    for backup (i.e. when connectivity via the VPN is down)?  Is a
    "site" always completely disconnected (topologically) from other
    sites (other than via the VPN service)?
 3. Somewhat related, I am trying to understand the difference between a
    site with sub-VPNs (i.e. each site-access-link is connected to a
    different VPN) vs treating it as two sites, each with a single
    site-access-link.  The text says a sub-VPN "is similar to having
    separate sites, but in this case the customer wants to share some
    physical components while maintaining strong communication
    isolation".  Does "this case" mean the sub-VPN case or the multiple
    sites case?  Either way, the customer could share physical
    components and maintain strong isolation, right?
 4. Under the VPN service, there is a leaf for the customer name. If the
    model is supposed to represent the request from a customer to the
    SP, I would have thought the customer name would be known
    out-of-band, e.g. from the AAA for the request?  It would be bad if
    one customer could request things for another customer by filling in
    a different customer name in the model!
 5. For cloud access, a single VPN can connect to multiple cloud
    services, and for each cloud service you have to specify which sites
    are authorized to access the cloud.  Is there a reason it was
    modelled this way, rather than having a separate VPN service to
    connect to each cloud service?  If there was a separate VPN service
    for each cloud service, then only the right sites would be attached
    to the VPN for each cloud, and it would not be necessary to have a
    separate list of authorized sites, right?
 6. On that subject, the yang module has
    /l3vpn-svc/vpn-services/vpn-service/cloud-accesses/cloud-access/list-flavor,
    which is a choice of permit-any, permit-any-except and
    deny-any-except.  It also has
    /l3vpn-svc/vpn-services/vpn-service/cloud-accesses/cloud-access/authorized-sites
    and
    /l3vpn-svc/vpn-services/vpn-service/cloud-accesses/cloud-access/denied-sites,
    which seem to serve the same purpose.  This looks like an error -
    was one of these supposed to be deleted?  If not, what is the
    difference?  I noticed that section 6.2.2 only mentions the first
    one (list-flavor/...).
 7. Sticking with cloud access, there is an option for enabling NAT44. 
    However, only a single address can be specified.  For some big
    enterprise customers, when NAT is used, more than one public-facing
    address is needed (typically from the same IP prefix) - is there a
    way to accommodate that case?
 8. There is a 'svc-mtu' leaf under the site-network-access; however,
    it's not mentioned in section 6 and it's not clear how it's intended
    to be used.  At least for IPv4, packets larger than the MTU can be
    fragmented (although that might be undesirable, so it might be
    useful to have a per-VPN knob to disable it).  I think the minimum
    requirement is that the customer and the SP agree on the lowest MTU
    across the whole VPN, so that the customer can be certain that
    packets shorter than that will be delivered.  Of course, the
    customer might use techniques like path MTU discovery to determine
    that they can use a larger MTU for particular paths.  I think it
    would be useful to have some discussion of this topic in the RFC.
 9. There is a per-site limit on the number of  IPv4/IPv6 routes
    ("maximum-routes") - is this the maximum number of routes that can
    be advertised by the customer towards the SP at that site? In a
    multi-VPN case, would it be useful to have a per-site, per-VPN
    limit, e.g. in the case where one of the VPNs is an extranet, to
    limit the number of prefixes that can be advertised into the
    extranet at that site?
10. There is a qos-classification-policy (either per-site or
    per-site-network-access), which describes how to map packets to the
    right class of service.  In a single-VPN case, this is fine, but I
    am not sure how to interpret it when the site is attached to
    multiple VPNs.  The different VPNs might have different classes of
    service, so doesn't the classification policy need to be per-site
    per-VPN, not just per-site?
11. The related qos-profile has constraints on latency and jitter;
    however, these apply to all packets in a flow.  So, for example, if
    there were sites in London, Paris and San Francisco, the same
    latency constraint would apply to packets from London to Paris and
    packets from London to San Francisco, which doesn't seem very
    useful.  Similarly, in a multi-VPN case, the same constraints would
    apply regardless of which VPN the packet maps to.  This type of
    constraint would normally be in an SLS, but I thought in general the
    approach was to avoid trying to specify an SLS in the model?
12. On similar lines, in the qos-profile there is a
    guaranteed-bandwidth, which can either be for just the access, or
    can be end-to-end.  How should an end-to-end bandwidth guarantee be
    interpreted if the VPN has more than two sites?  Or does it only
    make sense for a P2P case?
13. Lots of questions about the routing-protocols:
     1. When the routing protocol is "direct", the SP routes traffic
        towards the prefix specified by the connection address; however,
        one would expect that they always do this regardless of what
        other routing protocol is in use, right?  So, what is the
        difference between specifying routing protocol "direct", and
        leaving the routing protcol list empty?
     2. The purpose of VRRP is to be opaque to the customer - so it's
        not clear why the customer would explicitly request this?  Is
        the intent to capture that the customer wants to ensure there is
        redundancy of the access link at L2? If so, perhaps it would be
        better handled by having some sort of access constraint for
        "l2-diverse"?
     3. For OSPF, doesn't some information on the timers (hello
        interval, dead interval, retransmit interval) need to be
        exchanged, so that the customer and SP can configure their
        devices in such a way that they won't time each other out?
        Perhaps the intent is that the SP specifies these, and it's not
        covered in the model (going back to my first question)? If so,
        it would be useful to make this explicit.
     4. For OSPF, a metric can be specified - the only description is
        "Metric of the PE-CE link".  How is this intended to be used? 
        How does this relate to the 'access-priority' for the
        site-network-accesses, which is supposed to be used to influence
        load-sharing and active/standby?
     5. For BGP, there is an AS number, but is it supposed to be the
        customer's AS number or the SP's AS number?  The description
        just says "AS Number", which is not very illuminating.
     6. Also I think there is a lot more that would need to be agreed on
        for BGP; for instance, the timers (similar to the OSPF case),
        authentication (e.g. MD5+password), whether the SP will apply
        "AS override" behaviour, etc.
     7. For dual-stack BGP, the text says it is up to the SP to decide
        whether to use one session or two sessions - but clearly the
        customer needs to know this too so that they can configure their
        devices accordingly.  Is that intended to be outside the scope
        of the model?  It would be useful to clarify it.
     8. It also says that the session addressing is derived from the
        connection parameters - this is a common case, but not the only
        way to do it.  For example, if there are multiple
        site-network-accesses, then the SP may decide to use a single
        BGP session between loopbacks, using EBGP-multihop, rather than
        a separate BGP session on each site-network-access.  Can the
        model accomodate this case?
     9. For static routing, each prefix has a mandatory nexthop;
        however, for P2P L2 technologies (e.g. PPP, ATM), the nexthop
        might not be needed, right?
14. Lots of parameters can be specified either on the site or on the
    site-network-access.  However, BFD can only be specified on the
    site-network-access.  Is there a reason for this?  I would have
    thought if you want BFD on one site-network-access, you probably
    want it on all of them, with the same parameters, so having the
    possibility of specifying it once under the site would seem useful.
15. Some questions about the IPv4/IPv6 connection for each
    site-network-access:
     1. When DHCP is used, the provider address and mask aren't
        specified - but doesn't the customer need to know this, so as to
        avoid allocating addresses within that prefix to their internal
        devices?  Or does this again fall into the category of
        information passed from the SP to the customer, and hence not in
        the scope of the model?
     2. Similarly, when DHCP is used, the customer may still want some
        statically-assigned hosts on that subnet (e.g. for servers
        etc).  There is a leaf for saying how many DHCP addresses are
        being requested, but I think the customer would also need to
        know which addresses, so that they can assign other addresses on
        that subnet statically, right?
     3. When DHCP-Relay is used, does it make sense to have a multi-VPN
        case?  I'm not sure how the SP would know which VPN to forward
        the DHCP requests over in this case.
     4. For IPv6 connection, is there a case where only link-local
        addresses are used?
16. Under the site-network-access, there is a svc-input-bandwidth and
    svc-output-bandwidth.  Section 6.12.1 says that input/output is from
    the site's perspective, i.e. "input bandwidth" means download from
    the SP towards the site, and "output bandwidth" means upload from
    the site towards the SP.  However, the descriptions of the leaves
    within the module say the opposite: svc-input-bandwidth is "From the
    PE's perspective, the service input bandwidth of the connection."
    and likewise for output.  To my mind, expressing this from the SP's
    perspective makes more sense (i.e., it is input to or output from
    the VPN service) - but either way, the document should be consistent
    and not contradict itself.  Note that these leaves are also refered
    to in section 6.12.2.2 for the QoS profile - that text might also be
    affected when resolving the conflict.
17. The access-priority leaf is supposed to be used to define a
    preference for load-balancing or active/standby when there are
    multiple site-network-accesses.  However, it wasn't clear to me
    whether this was intended to apply to ingress traffic, egress
    traffic, or both; or how it relates to the routing protocol
    metrics/costs.  When the customer sends traffic towards the SP, they
    can chose whichever site-network-access they like, and the SP should
    deliver the traffic, so it seems that nothing needs to be specified
    in that case; if so, the access-priority would only apply to traffic
    flowing from the SP to the customer.  However, assuming a dynamic
    routing protocol is used, the customer ought to be able to influence
    that by advertising different metrics on the different
    site-network-accesses (provided the SP honours these).  The only
    more complex case I could think of is where there's a desire to
    ensure that traffic always flows bidirectionally on the same link -
    but then, I couldn't figure out how the access-priority could help
    with that.  Am I missing something?

Sorry for having so many questions!

Thanks in advance,


     David



On 09/05/2017 14:57, Qin Wu wrote:
> Dear L3SM list,
>
> As you saw, Jan did a very good review of the L3SM YANG model, and there has
> been a little discussion on this list.
>
> I am preparing a bis draft to include all of the comments. The plan is:
> - I show the draft to Jan and the authors of the RFC
> - I post the draft
> - We review it on this list
> - We ask Benoit to AD sponsor it
>
> I hope to have the revision ready very soon.
>
> Regards,
> Qin
>
>
> Sent from HUAWEI AnyOffice
>
>
> _______________________________________________
> L3sm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/l3sm

-- 
David Ball
<[e-mail]>