Subject: Re: [L3sm] Next Step of RFC8049

From: David Ball <[email-masked]>
Date: Fri, 2 Jun 2017 16:07:56 +0100

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l3sm

-- 
David Ball
<[email-masked]>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 8 Jun 2017 13:01:42 +0900

Hi David,

As an author and operator, see comments inline, please.
Stephane, luis, could you correct me if I misunderstand?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
Sent: Saturday, June 03, 2017 12:08 AM
To: Qin Wu; [email-masked]
Subject: 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?)

[KO] That's right.

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

[KO] This case of the backdoor is a corner case and a service model should not define such corner cases.

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?

[KO] This case means the sub-VPN case, and your indication is 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!  
	
[KO] A customer can only access the model instance of that customer. Please see section 10.

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?
	
[KO] That's 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/...).

[KO] I think you are right. deny-any-except looks same as authorized-sites, and permit-any-except does denied-sites.

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?

[KO] The current model can cover the case. SP just has to pick a range of addresses, but some augmentations, how many addresses are required, is desired.

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.

[KO] This leaf is required to be set the value if a customer requires to do so. But, I have no idea about the case.

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?
	
[KO] It may be useful, but a solution is required, and I don't know such an existing solution.

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?

[KO] As described in 6.12.2.1, where to classify and apply the qos is up to the SP, and outside of scope of this model.

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? 
	
[KO] Same comment as above. And, I agree with your thought about the SLS.

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?
	
[KO] Same comment as above. As I know, a SP controls the bandwidth at input/output of PE.

	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?

[KO] The list routing-protocol has the entity with "type" as the key. Then empty routing protocol is not allowed.

	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"?
		
[KO] From an operator's perspective, VRRP has common consensus for L3VPN customers rather than what l2-diverse means.

	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.

[KO] As you wrote, that's negotiated outside of this model.

	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?

[KO] As described above, I think how to behave the combination of a routing protocol and an access priority is up to a SP. The routing protocol may work on the active link specified by the access priority.

	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.
		
[KO] That's customer's AS number. It's obvious that a SP has an AS number for their L3VPN service. For example of KDDI, 9996 is our IPVPN AS number.

	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.

[KO] Same as OSPF. Some specific function should be augmented if a SP wants to use, although we want the authentication.

	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.
		
[KO] I think this is also communicated outside of the model.

	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?
		
[KO] The current model only supports the latter case. An argumentation is required if a SP wants to use the former one.

	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?

[KO] From a PE's perspective, the next hop for a LAN/subnet behind CE with PE-CE P2P link should be the CE end point of the P2P link.

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.

[KO] As you wrote, the current model can cover the case, if a SP wants to extend to inherit so,  he/she can augment.

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?
		
[KO] Agree. Even for the provider-dhcp case, a customer must at least be able to require the provider-addrss, PE address/subnet.

	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.
		
[KO] The customer must specify the DHCP server address, a SP just forwards a DHCP request there based on the routing table even in multi-VPN case.

	4.	For IPv6 connection, is there a case where only link-local addresses are used?

[KO] No, a global one is also supported.

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.

[KO] Agree.

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?

[KO] As above described, I think How this works is up to a SP.

Thanks in advance,

    David

	Dear L3SM list,

	
	
	Regards,
	Qin

	

-- 
David Ball
<[email-masked]> <mailto:[email-masked]>

---

From: David Ball <[email-masked]>
Date: Mon, 12 Jun 2017 15:39:23 +0100

Thanks Kenichi, please see further thoughs inline:

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

[DB]: Ok, thanks.  Qin, if you are developing a bis version, it would 
definitely help to make this clearer near the start of the doc.

> [KO] This case of the backdoor is a corner case and a service model should not define such corner cases.

[DB] Ok - but what about my more general question?  Is a single site 
always assumed to be topologically disconnected from other sites?

> [KO] This case means the sub-VPN case, and your indication is right.

[DB].  Ok - if it the same as using multiple sites (which would still be 
topologically separate even if they use the same physical components), I 
guess I don't understand the purpose of having sub-VPN as an option - 
but good to know there is nothing extra I'm missing here.

> [KO] A customer can only access the model instance of that customer. Please see section 10.

[DB] Yes exactly - if a customer can only access their own instance of 
the model, why does the customer name need to be specified within the 
model?  You already know you are dealing with that customer's instance 
of the model.  It seems like the customer-name leaf is unnecessary?

> 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 mo…

[DB] So is there a reason it was not done that way?

> [KO] I think you are right. deny-any-except looks same as authorized-sites, and permit-any-except does denied-sites.

[DB] Qin, will you be fixing this in the bis version?

> [KO] The current model can cover the case. SP just has to pick a range of addresses, but some augmentations, how many addresses are required, is desired.

[DB] Ok.

> [KO] This leaf is required to be set the value if a customer requires to do so. But, I have no idea about the case.

[DB] Anyone else?  It doesn't seem useful to have a leaf in the model if 
we don't know what it means...

> [KO] It may be useful, but a solution is required, and I don't know such an existing solution.

[DB]: Ok, yes I can see how implementing that might not be straightforward.

> [KO] As described in 6.12.2.1, where to classify and apply the qos is up to the SP, and outside of scope of this model.

[DB] Agreed, but that wasn't my question.  The question is, in a 
multi-VPN case, don't you want a different QoS policy for each VPN at 
the site?

> [KO] Same comment as above. And, I agree with your thought about the SLS.

[DB] Ok.  I don't know when this was added, I don't remember seeing it 
in the drafts I looked at at the time. Do you think it should be removed 
in Qin's bis version?

> [KO] Same comment as above. As I know, a SP controls the bandwidth at input/output of PE.

[DB] Agreed - but again, the question is about the meaning of the 
attribute rather than where the SP implements it.  In a VPN with 10 
sites, what does it mean to say that the end-to-end bandwidth is 10Mb/s?

> [KO] The list routing-protocol has the entity with "type" as the key. Then empty routing protocol is not allowed.

[DB] I meant an empty list, not an empty element in the list. There is 
no "min-elements" on the routing-protocol list, so the list itself could 
be empty.

> [KO] From an operator's perspective, VRRP has common consensus for L3VPN customers rather than what l2-diverse means.

[DB] Ok.

> [KO] As you wrote, that's negotiated outside of this model.

[DB] Ok.

> [KO] As described above, I think how to behave the combination of a routing protocol and an access priority is up to a SP. The routing protocol may work on the active link specified by the access p…

[DB] I don't see how a customer will be able to use these parameters 
correctly/appropriately if the corresponding behaviour isn't clearly 
described.  What is expected to happen if the customer sets the OSPF 
metric to a particular value?
(Also, if it is a provider-managed CE, is this really the metric of the 
PE-CE link?)

> [KO] That's customer's AS number. It's obvious that a SP has an AS number for their L3VPN service. For example of KDDI, 9996 is our IPVPN AS number.

[DB] I think it would be useful to clarify it.  Qin?

> [KO] Same as OSPF. Some specific function should be augmented if a SP wants to use, although we want the authentication.

[DB] Ok.

> [KO] I think this is also communicated outside of the model.

[DB] Ok.

> [KO] The current model only supports the latter case. An argumentation is required if a SP wants to use the former one.

[DB] Ok.

> [KO] From a PE's perspective, the next hop for a LAN/subnet behind CE with PE-CE P2P link should be the CE end point of the P2P link.

[DB] Right, but for a P2P L2 technology, the IP nexthop doesn't need to 
be specified, right?

> [KO] As you wrote, the current model can cover the case, if a SP wants to extend to inherit so,  he/she can augment.

[DB] Agreed - but I was wondering if there was a reason it was done this 
way originally?  Or was it just an oversight?

> [KO] Agree. Even for the provider-dhcp case, a customer must at least be able to require the provider-addrss, PE address/subnet.

[DB] I guess given your other answers, this would be outside the scope 
of the model?

> [KO] The customer must specify the DHCP server address, a SP just forwards a DHCP request there based on the routing table even in multi-VPN case.

[DB] Ok.

> [KO] No, a global one is also supported.

[DB] I meant, if the customer wanted to use only LL addresses on the 
link, is there a way to specify that?

> 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 downl…

[DB] Qin, will you fix this?

> [KO] As above described, I think How this works is up to a SP.

[DB] Ok - but it doesn't seem very useful if the customer doesn't know 
how the SP will use it; how will the customer know what to request?

     David

-- 
David Ball
<[email-masked]>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Wed, 14 Jun 2017 18:09:43 +0900

Hi David,

Thanks for you comments.
See more comments inline, please.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
Sent: Monday, June 12, 2017 11:39 PM
To: Ogaki, Kenichi; 'Qin Wu'; [email-masked]
Subject: Re: [L3sm] Next Step of RFC8049

	Hi David,

	Thanks,
	Kenichi
	
	-----Original Message-----
	From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
	Sent: Saturday, June 03, 2017 12:08 AM
	To: Qin Wu; [email-masked]
	Subject: Re: [L3sm] Next Step of RFC8049
	
	Hi Qin,

	
	[KO] That's right.

[DB]: Ok, thanks.  Qin, if you are developing a bis version, it would definitely help to make this clearer near the start of the doc.

[DB] Ok - but what about my more general question?  Is a single site always assumed to be topologically disconnected from other sites?

[KO] I don't think so. If a customer connects two sites with a backdoor and appropriately advertises both sites' routes to both connected PEs by using a dynamic routing protocol, both sites should still be reachable when the break of one of PE-CE links occurs.

[DB].  Ok - if it the same as using multiple sites (which would still be topologically separate even if they use the same physical components), I guess I don't understand the purpose of having sub-VPN as an option - but good to know there is nothing extra I'm missing here.

[KO] Sub-VPN is a real-life usecase provided in commercial VPN services.

[DB] Yes exactly - if a customer can only access their own instance of the model, why does the customer name need to be specified within the model?  You already know you are dealing with that customer's instance of the model.  It seems like the customer-name leaf is unnecessary?

[KO] As common usecases, a VPN service is provided not only by Tier 1 providers, but also by Tier 2 providers or IT divisions of enterprises in order to provide their own end users by using a Tier 1 provider's VPN service. Such customers usually requires this kind of attributes for their management purposes.

	[KO] That's right.

[KO] The requirement that a VPN want to connect multiple clouds still exists. The latter case cannot cover this.

	

[DB] Ok.

[DB] Anyone else?  It doesn't seem useful to have a leaf in the model if we don't know what it means...

	

[DB] Agreed, but that wasn't my question.  The question is, in a multi-VPN case, don't you want a different QoS policy for each VPN at the site?

[KO] As I wrote below, we need at least classify/apply a qos at input/output of PE, not differentiate it per VPN. But, other SPs may want this.

[DB] Ok.  I don't know when this was added, I don't remember seeing it in the drafts I looked at at the time.  Do you think it should be removed in Qin's bis version?

[KO] I don't think so. If a SP wants to allow the customer to specify the latency or jitter from London to Paris, this can work. It's up to an SP.

[DB] Agreed - but again, the question is about the meaning of the attribute rather than where the SP implements it.  In a VPN with 10 sites, what does it mean to say that the end-to-end bandwidth is 10Mb/s?

[KO] For our case, this means not an end-to-end qos, but an access qos. If a SP wants an end-to-end qos, he/she must negotiate some constraints or conditions with her/his customer outside of this model.

[DB] I meant an empty list, not an empty element in the list.  There is no "min-elements" on the routing-protocol list, so the list itself could be empty.

[KO] I understand. I think it should specify the "min-elements" with one entity. But, we may be able to understand the case as the direct, if the list is empty.

[DB] Ok.

[DB] Ok.

[DB] I don't see how a customer will be able to use these parameters correctly/appropriately if the corresponding behaviour isn't clearly described.  What is expected to happen if the customer sets the OSPF metric to a particular value?
(Also, if it is a provider-managed CE, is this really the metric of the PE-CE link?)

[KO] As I wrote, a SP must inform how this mechanism works to his/her customer outside of this model. It depends on each SP's implementation.

	

[DB] Ok.

[DB] Ok.

[DB] Ok.

[DB] Right, but for a P2P L2 technology, the IP nexthop doesn't need to be specified, right?

[KO] That's right. But, I think it's same as the direct case described in 6.11.2, and don't need even static routing.

[DB] Agreed - but I was wondering if there was a reason it was done this way originally?  Or was it just an oversight?

[KO] I think, if a solution covers two requirements, each solution for each requirement is not always necessary.

			

[DB] I guess given your other answers, this would be outside the scope of the model?

[KO] No, I think the model should definitely specify this.

[DB] Ok.

[DB] I meant, if the customer wanted to use only LL addresses on the link, is there a way to specify that?

[KO] The customer just has not to assign a global address. But, the model may be better to definitely specify which type of IPv6 address is used.

	[KO] Agree.

	

[DB] Ok - but it doesn't seem very useful if the customer doesn't know how the SP will use it; how will the customer know what to request?

[KO] As described above, a SP must inform how this mechanism works to his/her customer outside of this model.

    David

		Dear L3SM list,

		
		
		Regards,
		Qin

---

From: David Ball <[email-masked]>
Date: Tue, 20 Jun 2017 18:32:50 +0100

Thanks Kenichi - more comments inline.  It would be great to hear some 
other opinions too.

> [KO] I don't think so. If a customer connects two sites with a backdoor and appropriately advertises both sites' routes to both connected PEs by using a dynamic routing protocol, both sites should…

[DB2]
Ok - so in general, if the Subscriber has a number of access connections 
(i.e. site-network-accesses) connecting various parts of their network 
(wherever they are located) to the SP, it is up to them to determine how 
to group them into sites?

> [KO] Sub-VPN is a real-life usecase provided in commercial VPN services.

[DB2]
Sure, I am not disputing that this set-up exists; my question is why it 
should be modelled as a sub-VPN instead of modelling at separate sites?  
The same scenario can be expressed either way, right?

> [KO] As common usecases, a VPN service is provided not only by Tier 1 providers, but also by Tier 2 providers or IT divisions of enterprises in order to provide their own end users by using a Tier…

[DB2]
I didn't really follow this, sorry.  The module contains the information 
that needs to be sent from the customer to the SP, right?  If the 
customer using the model (i.e. the Tier2 in your above example) needs to 
track which of their own customers the service is for, that's something 
that's internal to them, isn't it?

> [KO] The requirement that a VPN want to connect multiple clouds still exists. The latter case cannot cover this.

[DB2]
Can you give an example that can be modelled with multiple clouds in a 
single VPN that could not be modelled as multiple VPNs?

> [KO] As I wrote below, we need at least classify/apply a qos at input/output of PE, not differentiate it per VPN. But, other SPs may want this.

[DB2] Right - so shouldn't the model support it?

> [KO] I don't think so. If a SP wants to allow the customer to specify the latency or jitter from London to Paris, this can work. It's up to an SP.

[DB2] Right, but the way the model is, the model can't be used to 
specify the latency or jitter from London to Paris, it is just a single 
value for the VPN as a whole.

> [KO] For our case, this means not an end-to-end qos, but an access qos. If a SP wants an end-to-end qos, he/she must negotiate some constraints or conditions with her/his customer outside of this m…

[DB2] My question was specifically about when the end-to-end leaf is set 
to true.

> [KO] I understand. I think it should specify the "min-elements" with one entity. But, we may be able to understand the case as the direct, if the list is empty.

[DB2] Right - so if the "direct" case can be represented by an empty 
list, then there is no need to explicitly specify "direct".

> [KO] As I wrote, a SP must inform how this mechanism works to his/her customer outside of this model. It depends on each SP's implementation.

[DB2] Ok; in my opinion, having things in the model without any 
information about how they should be used is not useful, but so be it.

> [KO] That's right. But, I think it's same as the direct case described in 6.11.2, and don't need even static routing.

[DB2] Ok.

> [KO] I think, if a solution covers two requirements, each solution for each requirement is not always necessary.

[DB2] Agreed - my question is why, in this particular case, only the 
per-access solution was included whereas for other attributes, both 
mechanisms were included.  What was the specific rationale for not 
adding BFD as a per-site attribute?

> [KO] No, I think the model should definitely specify this.

[DB2] Ok.  Qin, should we add this?

> [KO] The customer just has not to assign a global address. But, the model may be better to definitely specify which type of IPv6 address is used.

[DB2] Right, I don't think this can be specified in the model at the 
moment.  Qin, something else to add?

     David

-- 
David Ball
<[email-masked]>

---

From: <[email-masked]>
Date: Wed, 21 Jun 2017 09:56:20 +0000

Hi,

Please find some comments inline (marked with [SLI])

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
Sent: Tuesday, June 20, 2017 19:33
To: Ogaki, Kenichi; 'Qin Wu'; [email-masked]
Subject: Re: [L3sm] Next Step of RFC8049

Thanks Kenichi - more comments inline.  It would be great to hear some other opinions too.

[DB2]

[SLI] The site is a notion that is defined by the customer. It could be a single physical location or it could be a kind of customer point of presence in a city with multiple physical locations (e.g. two buildings in two areas of a city).
This flexibility is required for multihoming, as a lot of customers host the two CPEs in two different physical locations.

[DB2]

[SLI] We had this debate earlier when modeling the subVPN (using multiple sites was one of the possibility but not retained).
The subVPNs has the particularity of sharing a common bearer and a common CPE (it's a VRF lite CPE in term of configuration).

[DB2]

[DB2]

[SLI] Using multiple VPNs has a major impact on the service design (not talking about implementation). From a service perspective, let's say that the customer starts with an any to any VPN where all sites can communicate with each other.
After some months, it requires a cloud interconnection, so it's hub site can spawn VM in AWS for example but the other sites should not access to AWS. From a service perspective, you need to model it as a list of authorized/unauthorized sites.
Now in term of implementation, you can do what you want, you can create additional VPNs, you can use ACLs or whatever... but from a service perspective, the customer has a single VPN and a cloud access with limited access.

> [DB] Qin, will you be fixing this in the bis version?

[SLI] oh yes, authorized-sites/denied-sites was an old style of modeling that we normally removed (it seems that we missed to remove it).

> [DB] Anyone else?  It doesn't seem useful to have a leaf in the model if we don't know what it means...
[SLI] This was mainly introduced for two use cases:
- customer requiring a specific IPv4 or IPv6 MTU (jumbo MTU)
- carrier's carrier case where the connection is an MPLS connection and not more IP, so we need to know what is expected in term of "mpls mtu"
For sure the customer needs to fill consistent informations in order to make it working.

[DB2] Right - so shouldn't the model support it?
[SLI] I'm not sure this is necessary, in the multiVPN case, the site is "shared", so the customer expects flows to go to sites that are located in different VPNs. The customer can use the dst-prefix or the target-site in order to set a particular class for a particular flow whatever the VPN.

[SLI] I think you can, you just need more classes. 
You create a class#1 with target-site SFO, a class#2 with target-site Paris or whatever. Then in the profile you can set a different latency or guaranteed BW...

[SLI] The main use case is P2P, but if it is set for a class which involves more than two sites, the reservation will be done to all the sites involved.

[SLI] Some SPs prevents to advertise the interco subnet except if the customer really requires it.

[DB2] Ok.

     David

-- 
David Ball
<[email-masked]>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Qin Wu <[email-masked]>
Date: Thu, 22 Jun 2017 05:20:59 +0000

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:[email-masked]]
发送时间: 2017年6月2日 23:08
收件人: Qin Wu; [email-masked]
主题: Re: [L3sm] Next Step of RFC8049

Hi Qin,

  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?

Thanks in advance,

    David

Regards,
Qin

L3sm mailing list

[email-masked]<mailto:[email-masked]>

--

David Ball

<[email-masked]><mailto:[email-masked]>

---

From: David Ball <[email-masked]>
Date: Thu, 22 Jun 2017 13:25:37 +0100

Thanks Stephane - responses in line (marked [DB3]):

> This flexibility is required for multihoming, as a lot of customers host the two CPEs in two different physical locations.

[DB3]
Ok, thanks - that is what I thought, but it could be described more 
clearly in the RFC I think.

> The subVPNs has the particularity of sharing a common bearer and a common CPE (it's a VRF lite CPE in term of configuration).

[DB3]
I agree that two site network accesses in the same site and using a 
subVPN can share a common bearer and a common CPE, but two 
site-network-accesses in different sites could also share a common 
bearer and a common CPE, right?  Per your answer above, the site is a 
notion defined by the customer, so couldn't they designate two site 
network accesses as being in different sites even if they share the same 
bearer?

I understand what subVPN *can* do - what I'm trying to understand is 
whether there is anything that *can't* be done with multiple sites. The 
text suggests that there is some functional difference between these two 
approaches, but if so, I don't understand what it is.  It would be 
helpful to either make the text clearer about the difference, or else 
change it to say that the two approaches are functionally the same.

> Now in term of implementation, you can do what you want, you can create additional VPNs, you can use ACLs or whatever... but from a service perspective, the customer has a single VPN and a cloud ac…

[DB3]
Ok - but in this scenario, why wouldn't the customer just get a new 
service connecting the hub site to the cloud when they need it?
I can see why it might be treated, commercially, as part of the same 
*product*, but I don't understand why it would need to be the same 
*service*?

> For sure the customer needs to fill consistent informations in order to make it working.

[DB3]
Right - so this could use some more explanation in the text I think.

> [SLI] I'm not sure this is necessary, in the multiVPN case, the site is "shared", so the customer expects flows to go to sites that are located in different VPNs. The customer can use the dst-prefi…

[DB3]
Right, but it would be very easy with this mechanism for the customer to 
make a mistake and have a policy that maps a packet that will go to a 
site in one VPN to a class that only exists in the other VPN; and 
moreover, it would be hard for the SP to check this. Would it not be 
better to design the model so that these sorts of consistency checks are 
implicit in the structure of the model, rather than relying on the 
customer not to make a mistake?

Of course, if all the VPNs have the same set of classes, then there is 
no issue.  Perhaps that is the common case?

> You create a class#1 with target-site SFO, a class#2 with target-site Paris or whatever. Then in the profile you can set a different latency or guaranteed BW...

[DB3]
Ah, yes I guess you could do it that way.

> [SLI] The main use case is P2P, but if it is set for a class which involves more than two sites, the reservation will be done to all the sites involved.

[DB3]
So, for example, suppose I have a VPN with 5 sites, with the following 
settings:
  * Site A: svc-input-bandwidth = svc-output-bandwidth = 100000000, for 
class "foo" guaranteed-bw-percent = 10, end-to-end = true
  * Site B: svc-input-bandwidth = svc-output-bandwidth = 200000000, for 
class "foo" guaranteed-bw-percent = 20, end-to-end = true
  * Site C: svc-input-bandwidth = svc-output-bandwidth = 300000000, for 
class "foo" guaranteed-bw-percent = 30, end-to-end = true
  * Site D: svc-input-bandwidth = svc-output-bandwidth = 400000000, for 
class "foo" guaranteed-bw-percent = 40, end-to-end = true
  * Site E: svc-input-bandwidth = svc-output-bandwidth = 500000000, for 
class "foo" guaranteed-bw-percent = 50, end-to-end = true

What does this mean?  What bandwidth is reserved between each of the 10 
pairs of sites?

If end-to-end is false for all the sites, I think the meaning is clear, 
e.g. at site A, 10% of 100000000, i.e. 10000000 is reserved across the 
access for traffic in class "foo", and at site D, 40% of 400000000, i.e. 
160000000 is reserved across the access for traffic in class "foo".  But 
I cannot guess what this means when end-to-end is true...

> [SLI] Some SPs prevents to advertise the interco subnet except if the customer really requires it.

[DB3]
Sorry I did not understand how this relates to the issue?

     David

-- 
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Sat, 24 Jun 2017 09:18:52 +0000

Sorry to chime in, a few comments line (marked with [Qin]).
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 David Ball
发送时间: 2017年6月22日 20:26
收件人: [email-masked]; Ogaki, Kenichi; Qin Wu; [email-masked]
主题: Re: [L3sm] Next Step of RFC8049

On 21/06/2017 10:56, [email-masked] wrote:
> Sure, I am not disputing that this set-up exists; my question is why 
> it should be modelled as a sub-VPN instead of modelling at separate sites?

[DB3]
I agree that two site network accesses in the same site and using a subVPN can share a common bearer and a common CPE, but two site-network-accesses in different sites could also share a common bearer and a common CPE, right?  Per your answer above, the site is a notion defined by the customer, so couldn't they designate two site network accesses as being in different sites even if they share the same bearer?

I understand what subVPN *can* do - what I'm trying to understand is whether there is anything that *can't* be done with multiple sites. The text suggests that there is some functional difference between these two approaches, but if so, I don't understand what it is.  It would be helpful to either make the text clearer about the difference, or else change it to say that the two approaches are functionally the same.

[Qin]: How does two site-network-access belonging to two different site share the same bearer or physical component?

> Now in term of implementation, you can do what you want, you can create additional VPNs, you can use ACLs or whatever... but from a service perspective, the customer has a single VPN and a cloud ac…

[DB3]
Ok - but in this scenario, why wouldn't the customer just get a new service connecting the hub site to the cloud when they need it?
I can see why it might be treated, commercially, as part of the same *product*, but I don't understand why it would need to be the same *service*?

[Qin]:This provides fine granularity control on a site getting access to public cloud or internet.
You may also add a new site to an existing VPN, but this site may not have authorization to get access to public cloud unless you explicitly configure it.

[DB3]

[Qin]: Sure.
> [SLI] I'm not sure this is necessary, in the multiVPN case, the site is "shared", so the customer expects flows to go to sites that are located in different VPNs. The customer can use the dst-prefi…

[DB3]
Right, but it would be very easy with this mechanism for the customer to make a mistake and have a policy that maps a packet that will go to a site in one VPN to a class that only exists in the other VPN; and moreover, it would be hard for the SP to check this. Would it not be better to design the model so that these sorts of consistency checks are implicit in the structure of the model, rather than relying on the customer not to make a mistake?

Of course, if all the VPNs have the same set of classes, then there is no issue.  Perhaps that is the common case?

[Qin]: Attaching site to appropriate VPN is realized using vpn-attachment, either referencing VPN directly or referencing vpn policy. In that way, site will know to which VPN the packet should be forwarded.

> [DB2] My question was specifically about when the end-to-end leaf is 
> set to true.
>

[DB3]
So, for example, suppose I have a VPN with 5 sites, with the following
settings:
  * Site A: svc-input-bandwidth = svc-output-bandwidth = 100000000, for class "foo" guaranteed-bw-percent = 10, end-to-end = true
  * Site B: svc-input-bandwidth = svc-output-bandwidth = 200000000, for class "foo" guaranteed-bw-percent = 20, end-to-end = true
  * Site C: svc-input-bandwidth = svc-output-bandwidth = 300000000, for class "foo" guaranteed-bw-percent = 30, end-to-end = true
  * Site D: svc-input-bandwidth = svc-output-bandwidth = 400000000, for class "foo" guaranteed-bw-percent = 40, end-to-end = true
  * Site E: svc-input-bandwidth = svc-output-bandwidth = 500000000, for class "foo" guaranteed-bw-percent = 50, end-to-end = true

What does this mean?  What bandwidth is reserved between each of the 10 pairs of sites?

[Qin]: set end to end leaf as true means bandwidth reservation is applied to end to end connectivity, across MPLS transport network.
Set end to end leaf as false means bandwidth reservation is only applied to access connectivity for customer site.
Choose class "foo" with specific target site, we know from which site to which site bandwidth reservation needs to be performed.

[DB3]

[Qin]: Why not specify direct route in the model if direct route need to be supported? We could ad min-element "1" to make sure the list cannot be empty.

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Mon, 26 Jun 2017 12:23:19 +0900

Hi David, Qin,

See comments inline[KO3], please.
I also added Qin's comment to previous one.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
Sent: Thursday, June 22, 2017 9:26 PM
To: [email-masked]; Ogaki, Kenichi; 'Qin Wu'; [email-masked]
Subject: Re: [L3sm] Next Step of RFC8049

On 21/06/2017 10:56, [email-masked] wrote:
> Ok - so in general, if the Subscriber has a number of access 
> connections (i.e. site-network-accesses) connecting various parts of 
> their network (wherever they are located) to the SP, it is up to them 
> to determine how to group them into sites?
>

[DB3]
Ok, thanks - that is what I thought, but it could be described more clearly in the RFC I think.

[DB3]

[KO3] 
>but two site-network-accesses in different sites could also share a common bearer and a common CPE, right?

Yes and No. It's up to each SP's service. In *our* VPN service case, *No*, a common bearer is defined as a physical subscriber line with the demarcation device at *a* customer site, and then cannot be connected to two different sites. This is *our* service definition.
So, we need subVPN from the perspective of a service modelling, not technical aspect.

>I understand what subVPN *can* do - what I'm trying to understand is whether there is anything that *can't* be done with multiple sites.

Again, as Stephane wrote, the subVPN has the particularity of sharing *a common bearer* and a common CPE (interface).
And, I believe some SPs define a common bearer as above like us.

> I didn't really follow this, sorry.  The module contains the 
> information that needs to be sent from the customer to the SP, right?  
> If the customer using the model (i.e. the Tier2 in your above example) 
> needs to track which of their own customers the service is for, that's 
> something that's internal to them, isn't it?

[KO3] Yes, that's internal to them, but they (i.e. our customers) really request and are currently using this. Then, we need to model this.

[DB3]

[DB3]

[Qin]: Sure.

[DB3]

[KO3] As far as customers use standard qos profiles provided by their SP, this function should work well and I think that's common case.

> specify the latency or jitter from London to Paris, it is just a 
> single value for the VPN as a whole.
>

[DB3]

[DB3]

If end-to-end is false for all the sites, I think the meaning is clear, e.g. at site A, 10% of 100000000, i.e. 10000000 is reserved across the access for traffic in class "foo", and at site D, 40% of 400000000, i.e. 
160000000 is reserved across the access for traffic in class "foo".  But I cannot guess what this means when end-to-end is true...

[DB3]

[KO3] It's obviously better to specify the "min-elements" with one entity than to let users imply that an empty routing protocol list means the direct case.

     David

> adding BFD as a per-site attribute?

[KO3] I understand, but I'm not sure there is a specific rational for this case.

--
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Tue, 27 Jun 2017 12:41:53 +0100

Thanks Qin - more below tagged with [DB4].

> [Qin]: How does two site-network-access belonging to two different site share the same bearer or physical component?

[DB4]
Stephane said before "The site is a notion that is defined by the 
customer", and described how it could be a single location or multiple 
locations.  My interpretation was that a "site" is independent of 
location, so as well as having a single site spanning multiple 
locations, you could also have a multiple sites at a single location.  I 
took the meaning to be: a site is an arbitrary collection of site 
network accesses, independent of how or where they are connected.  With 
this interpretation, I don't see any problems with two 
site-network-accesses, belonging to two different "sites" but connecting 
to the same location, sharing the same bearer (e.g. different VLANs on 
the same phyiscal Ethernet link).

But perhaps I have extrapolated too far from what Stephane said?  Is the 
intent that a given location can only have a single site (but a site can 
span multiple locations)?

In any case, I think the RFC would benefit from some clearer description 
of exactly what is meant by a "site".

> You may also add a new site to an existing VPN, but this site may not have authorization to get access to public cloud unless you explicitly configure it.

[DB4]
Ok - so the same functionality could be achieved by just adding a new 
VPN in this case, but I guess the point is that it's easier to manage 
this way?

> [Qin]: Attaching site to appropriate VPN is realized using vpn-attachment, either referencing VPN directly or referencing vpn policy. In that way, site will know to which VPN the packet should be f…

[DB4]
Yes - the question was not about forwarding the packet, but about 
applying the QoS policy.

Perhaps an example will help to clarify the scenario I'm thinking of.

Suppose I have two VPNs, "foo" and "bar".  At a particular site, I use 
the VPN policy to attach the site to both "foo" and "bar", as a multiVPN 
attachment.

VPN "foo" has three classes of service, called H, M and L.
VPN "bar" also has three classes of service, called square, circle and 
triangle.

Now, for packets that are mapped to VPN "foo" (per the VPN policy), I 
need to set a QoS classification policy with target classes H, M and L.  
But, for packets that are mapped to VPN "bar" (per the VPN policy), I 
need to set a QoS classification policy with target classes square, 
circle and triangle.  However, with the model it is only possible to 
have a single QoS classification policy for the whole site.  So, I must 
configure a policy that has all six target classes (H, M, L, circle, 
square and triangle) and try to ensure that packets that will be mapped 
to VPN "foo" get target class H, M or L and packets that will be mapped 
to VPN "bar" get target class circle, square or triangle.  This is very 
hard since which VPN the packets get mapped to depends on routing 
information, which is dynamic.

I know this is a contrived example, but you can easily think of more 
realistic cases, e.g. the site is attached to both a VPN service with 
EF, AF and BE classes and also attached to an internet access service 
that only has a single class.

> Choose class "foo" with specific target site, we know from which site to which site bandwidth reservation needs to be performed.

[DB4] If the SP receives a request with the above data, what bandwidth 
do they need to reserve end-to-end between A and B, or between E and C?

> [Qin]: Why not specify direct route in the model if direct route need to be supported? We could ad min-element "1" to make sure the list cannot be empty.

[DB4]
My opinion would be the opposite - why force it to be specified if it's 
not needed?
Probably the best option is to leave it as it is, i.e. it can be 
specified or not.

     David

-- 
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Tue, 27 Jun 2017 12:52:57 +0100

Thanks Kenichi - there is one of your answers that I'm still confused 
about, see below:

> [KO3] Yes, that's internal to them, but they (i.e. our customers) really request and are currently using this. Then, we need to model this.

Perhaps I am misunderstanding the scenario.

If I understand correctly, the case is where the yang is being used 
between a Tier2 provider (lets call them T2-telecom) and Tier1 provider 
(lets call them T1-networks).  In other words, from the perspective of 
the RFC and the yang module, T1-networks is the SP and T2-telecom is the 
customer.

T2-telecom has their own customers call them (foo-bank, bar-supermarket 
and baz-advertising).  Whenever T2-telecom orders a new VPN from 
T1-networks, they want to record, in their internal systems, which of 
their end customers the new VPN is for.  Of course there is probably a 
lot of other information they want to store in their internal systems 
about their customers, such as contact info, billing and invoicing info, 
trouble tickets, etc.

What I don't understand is why T2-telecom would want to send the name of 
their end-customer (foo-bank, bar-supermarket or baz-advertising) to 
T1-networks as part of the netconf request when they order a new VPN.  
What is T1-networks going to do with this information?

     David

-- 
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Wed, 28 Jun 2017 02:30:47 +0000

Thanks David, please see my reply inline below tagged with [Qin-1]

-----邮件原件-----
发件人: David Ball [mailto:[email-masked]] 
发送时间: 2017年6月27日 19:42
收件人: Qin Wu; [email-masked]; Ogaki, Kenichi ([email-masked]); [email-masked]
主题: Re: [L3sm] Next Step of RFC8049

> [Qin]: How does two site-network-access belonging to two different site share the same bearer or physical component?

[DB4]
Stephane said before "The site is a notion that is defined by the customer", and described how it could be a single location or multiple locations.  My interpretation was that a "site" is independent of location, so as well as having a single site spanning multiple locations, you could also have a multiple sites at a single location.  I took the meaning to be: a site is an arbitrary collection of site network accesses, independent of how or where they are connected.  With this interpretation, I don't see any problems with two site-network-accesses, belonging to two different "sites" but connecting to the same location, sharing the same bearer (e.g. different VLANs on the same phyiscal Ethernet link).

But perhaps I have extrapolated too far from what Stephane said?  Is the intent that a given location can only have a single site (but a site can span multiple locations)?

In any case, I think the RFC would benefit from some clearer description of exactly what is meant by a "site".

[Qin-1]:Yes, Indeed, you extrapolate too much,:-), we will add a few text to clarify what the site is. Thanks!

>> Can you give an example that can be modelled with multiple clouds in 
>> a single VPN that could not be modelled as multiple VPNs?
>>

[DB4]
Ok - so the same functionality could be achieved by just adding a new VPN in this case, but I guess the point is that it's easier to manage this way?

[Qin-1] If my understanding is correct, Our assumption, is one VPN service can provide access to public cloud and provide cloud, data center network, we don't deem providing access to public cloud as a new VPN service,
Instead, it is part of existing VPN service.
Maybe you just have different model design.

> [Qin]: Attaching site to appropriate VPN is realized using vpn-attachment, either referencing VPN directly or referencing vpn policy. In that way, site will know to which VPN the packet should be f…

[DB4]
Yes - the question was not about forwarding the packet, but about applying the QoS policy.

Suppose I have two VPNs, "foo" and "bar".  At a particular site, I use the VPN policy to attach the site to both "foo" and "bar", as a multiVPN attachment.

VPN "foo" has three classes of service, called H, M and L.
VPN "bar" also has three classes of service, called square, circle and triangle.

Now, for packets that are mapped to VPN "foo" (per the VPN policy), I need to set a QoS classification policy with target classes H, M and L.  
But, for packets that are mapped to VPN "bar" (per the VPN policy), I need to set a QoS classification policy with target classes square, circle and triangle.  However, with the model it is only possible to have a single QoS classification policy for the whole site.  So, I must configure a policy that has all six target classes (H, M, L, circle, square and triangle) and try to ensure that packets that will be mapped to VPN "foo" get target class H, M or L and packets that will be mapped to VPN "bar" get target class circle, square or triangle.  This is very hard since which VPN the packets get mapped to depends on routing information, which is dynamic.

I know this is a contrived example, but you can easily think of more realistic cases, e.g. the site is attached to both a VPN service with EF, AF and BE classes and also attached to an internet access service that only has a single class. 

[Qin-1]: You forget that we also have target-sites defined under 'qos-classification-policy', target-sites will be an alternative way to identify the destination of a flow targeted to specific VPN besides using destination address, VPN-attachment tell us which site is attached to which VPN, no matter whether one site is attached to one VPN, or two VPNs. Combining VPN-attachment and target-sites, we will know how to map specific VPN(Indicated by target sites) to specific target class. Each site will also know how to correctly apply QoS policy.

>    * Site E: svc-input-bandwidth = svc-output-bandwidth = 500000000, 
> for class "foo" guaranteed-bw-percent = 50, end-to-end = true
>

[DB4] If the SP receives a request with the above data, what bandwidth do they need to reserve end-to-end between A and B, or between E and C?

[Qin-1]: Just like we use RSVP or RSVP-TE to reserve resource across network. If we specify target-sites under ' qos-classification-policy ', we will know from which source site to which target site the bandwidth needs to be reserved across the network. The target-sites could be a list,e.g, Site A is the source site, SiteB, Site D are part of target-sites list, we can reserve the same bandwidth from Site A to Site B as the one from Site A to Site D.

> [Qin]: Why not specify direct route in the model if direct route need to be supported? We could ad min-element "1" to make sure the list cannot be empty.

[DB4]
My opinion would be the opposite - why force it to be specified if it's not needed?
Probably the best option is to leave it as it is, i.e. it can be specified or not.

[Qin-1]: I like to argue why not respect direct route as many other optional routing protocol such as bgp, ospf.:-)  Many Thanks for your valuable comments.

     David

--
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Wed, 28 Jun 2017 02:37:46 +0000

David:
A few thoughts and comments below.
发件人: David Ball [mailto:[email-masked]]
发送时间: 2017年6月27日 19:53
收件人: Ogaki, Kenichi; [email-masked]; Qin Wu; [email-masked]
主题: Re: [L3sm] Next Step of RFC8049

Thanks Kenichi - there is one of your answers that I'm still confused about, see below:

[DB2]

If I understand correctly, the case is where the yang is being used between a Tier2 provider (lets call them T2-telecom) and Tier1 provider (lets call them T1-networks).  In other words, from the perspective of the RFC and the yang module, T1-networks is the SP and T2-telecom is the customer.

T2-telecom has their own customers call them (foo-bank, bar-supermarket and baz-advertising).  Whenever T2-telecom orders a new VPN from T1-networks, they want to record, in their internal systems, which of their end customers the new VPN is for.  Of course there is probably a lot of other information they want to store in their internal systems about their customers, such as contact info, billing and invoicing info, trouble tickets, etc.

What I don't understand is why T2-telecom would want to send the name of their end-customer (foo-bank, bar-supermarket or baz-advertising) to T1-networks as part of the netconf request when they order a new VPN.  What is T1-networks going to do with this information?

[Qin]:
1.With customer name,you could use it as a key to lookup detailed customer information such as contact info, billing info if needed.
2. You forget that VPN service is defined as a list of VPN Service. That is to say different VPN service could belong to different customer,
Adding customer name, we could know which customer has which VPN service.
3. customer name is just defined as an optional parameter. You don’t need to specify it in the case you don’t need it.
    David

--

David Ball

---

From: David Ball <[email-masked]>
Date: Wed, 28 Jun 2017 10:36:10 +0100

Hi Qin,

You have cycled this round to the start of the thread. :)  There must be 
some out-of-band way of identifying and authenticating the customer from 
whom the request is being received, otherwise customer foo could request 
a service for customer bar just by filling in a different value for this 
leaf in the model!  You are right that the VPN service is a list, but a 
given customer should only ever be able to use the model to access their 
own services, they should not be able to access services for any other 
customer.

     David

On 28/06/2017 03:37, Qin Wu wrote:
> *发件人:*David Ball [mailto:[email-masked]]
> *发送时间:*2017年6月27日19:53
> *收件人:*Ogaki, Kenichi; [email-masked]; Qin Wu; 
> [email-masked]
> *主题:*Re: [L3sm] Next Step of RFC8049
>
>             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!
>
>             [DB] Yes exactly - if a customer can only access their own
>             instance of the model, why does the customer name need to
>             be specified within the model?  You already know you are
>             dealing with that customer's instance of the model.  It
>             seems like the customer-name leaf is unnecessary?
>
>             [KO] As common usecases, a VPN service is provided not
>             only by Tier 1 providers, but also by Tier 2 providers or
>             IT divisions of enterprises in order to provide their own
>             end users by using a Tier 1 provider's VPN service. Such
>             customers usually requires this kind of attributes for
>             their management purposes.
>
>         [DB2]
>
>     [KO3] Yes, that's internal to them, but they (i.e. our customers)
>     really request and are currently using this. Then, we need to
>     model this.
>
>
> between a Tier2 provider (lets call them T2-telecom) and Tier1 
> provider (lets call them T1-networks).  In other words, from the 
> perspective of the RFC and the yang module, T1-networks is the SP and 
> T2-telecom is the customer.
>
> T2-telecom has their own customers call them (foo-bank, 
> bar-supermarket and baz-advertising).  Whenever T2-telecom orders a 
> new VPN from T1-networks, they want to record, in their internal 
> systems, which of their end customers the new VPN is for.  Of course 
> there is probably a lot of other information they want to store in 
> their internal systems about their customers, such as contact info, 
> billing and invoicing info, trouble tickets, etc.
>
> What I don't understand is why T2-telecom would want to send the name 
> of their end-customer (foo-bank, bar-supermarket or baz-advertising) 
> to T1-networks as part of the netconf request when they order a new 
> VPN.  What is T1-networks going to do with this information?
>
> [Qin]:
>
> 1.With customer name,you could use it as a key to lookup detailed 
> customer information such as contact info, billing info if needed.
>
> 2. You forget that VPN service is defined as a list of VPN Service. 
> That is to say different VPN service could belong to different customer,
>
> 3. customer name is just defined as an optional parameter. You don’t 
> need to specify it in the case you don’t need it.
>     David
>
>
> -- 
> David Ball

-- 
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Wed, 28 Jun 2017 11:30:10 +0000

Sort of,:-),how about add a few texts in security section to discuss security risk of disclosing customer name, hope this will address your comment . Thanks!

Sent from HUAWEI AnyOffice
发件人： daviball
收件人： Qin Wu; Ogaki, Kenichi; stephane.litkowski; l3sm;
主题： Re: [L3sm] Next Step of RFC8049
时间： 2017-06-28 17:36:30

Hi Qin,

You have cycled this round to the start of the thread. :)  There must be some out-of-band way of identifying and authenticating the customer from whom the request is being received, otherwise customer foo could request a service for customer bar just by filling in a different value for this leaf in the model!  You are right that the VPN service is a list, but a given customer should only ever be able to use the model to access their own services, they should not be able to access services for any other customer.

    David

收件人: Ogaki, Kenichi; [email-masked]<mailto:[email-masked]>; Qin Wu; [email-masked]<mailto:[email-masked]>

[DB2]

[Qin]:

--

David Ball

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Wed, 28 Jun 2017 20:43:04 +0900

Hi David,

At least in *our* service, a Tier2-provider just sells the Tier1-provider's service with some additional values, and the original service is operated by the Tier1-provider, not by the Tier2-provider. Then, a Tier1-provider must know which vpn/site/site-network-access is used by which end-user in order to provide smooth activation/commissioning and operation.

Thanks,
Kenichi

-----Original Message-----
From: David Ball [mailto:[email-masked]] 
Sent: Tuesday, June 27, 2017 8:53 PM
To: Ogaki, Kenichi; [email-masked]; 'Qin Wu'; [email-masked]
Subject: Re: [L3sm] Next Step of RFC8049

					

		[DB2]

    David

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Wed, 28 Jun 2017 20:46:14 +0900

Hi Qin,

This is already covered by Section 10.

And, I answered to David earlier.

Thanks,
Kenichi
-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: Wednesday, June 28, 2017 8:30 PM
To: [email-masked]; stephane.litkowski; l3sm; daviball
Subject: RE: [L3sm] Next Step of RFC8049

Hi Qin,

    David

	David:

	发件人: David Ball [mailto:[email-masked]] 
	发送时间: 2017年6月27日 19:53
	收件人: Ogaki, Kenichi; [email-masked] <mailto:[email-masked]> ; Qin Wu; [email-masked] <mailto:[email-masked]> 
	主题: Re: [L3sm] Next Step of RFC8049

				             

			[DB2]

	

	
	[Qin]:

---

From: Qin Wu <[email-masked]>
Date: Wed, 28 Jun 2017 12:00:38 +0000

Woops, I miss to check that. Thank for clarification.

-Qin
Sent from HUAWEI AnyOffice
发件人： ke-oogaki
收件人： Qin Wu; stephane.litkowski; l3sm; daviball;
主题： RE: [L3sm] Next Step of RFC8049
时间： 2017-06-28 19:56:23

Hi Qin,

Thanks,
Kenichi
-----Original Message-----
From: Qin Wu [mailto:[email-masked]]
Sent: Wednesday, June 28, 2017 8:30 PM
To: [email-masked]; stephane.litkowski; l3sm; daviball
Subject: RE: [L3sm] Next Step of RFC8049

Hi Qin,

    David

        David:

                        [DB2]

        [Qin]:

---

From: David Ball <[email-masked]>
Date: Thu, 29 Jun 2017 10:26:11 +0100

Ok, if this case is the reason for having the customer-name field in the 
model, then it definitely needs a lot more explanation!

     David

-- 
David Ball
<[email-masked]>