Re: [L3sm] Next Step of RFC8049

[Qin Wu <[e-mail]>]

Thanks David for taking a stab into RFC8049 and provide a lot of comments.  Sorry for late followup since I have just come back from a trip recently.
I think Kenichi and Stephane has already engaged into the discussion with you on the list.

I will cover your comments based on the discussing point in agreement after addressing Jan’s comments. Many thanks for your additional input.

-Qin
发件人: David Ball [mailto:[e-mail]]
发送时间: 2017年6月2日 23:08
收件人: Qin Wu; [e-mail]
主题: Re: [L3sm] Next Step of RFC8049


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:
     *   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?
     *   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"?
     *   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.
     *   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?
     *   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.
     *   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.
     *   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.
     *   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?
     *   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:
     *   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?
     *   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?
     *   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.
     *   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]<mailto:[e-mail]>

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



--

David Ball

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