From nobody Fri Jun 2 08:08:11 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5320412EBE8 for ; Fri, 2 Jun 2017 08:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlSuUcJQ6yGc for ; Fri, 2 Jun 2017 08:08:00 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137BC12EBF0 for ; Fri, 2 Jun 2017 08:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30709; q=dns/txt; s=iport; t=1496416080; x=1497625680; h=from:subject:to:references:message-id:date:mime-version: in-reply-to; bh=oxYgYOYXT92JOo+ttZMksYc1TKbZd5oG2dqeuMbBhqg=; b=bTJJuNRAiMEcEZArz1pF9jtxvjzzWU+NZM4j8ZXaY2KM1UWAsRhiOSjX jU9ynDz7AOAR6vs5aI9XHC3Pn21mwfJ3XdfBZ7N3HlvAFx/pUJTlfSsF2 GSJ+v5LKZOWWVwkwr/v55lf9PiT9198/uk2Voft54G2wMPhla18h65lyn E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAADmfTFZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDmBDY4Mc5EFlXyCDAMhAQqFeAKDOhgBAgEBAQEBAQFrKIUZAQE?= =?us-ascii?q?BAwEBGFQbCw4KGAgOJzAGAQwGAgEBiiYQrWoRg0grimABAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYZhgV8BK4J0gT2CcxcDTCKFJAWJPoZtgV2MJ5MrhUWFR4ZujCO?= =?us-ascii?q?IOR84gQowIQgbFUaFBgEEBxCBYgI/Noc1gj4BAQE?= X-IronPort-AV: E=Sophos;i="5.39,285,1493683200"; d="scan'208,217";a="653309172" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2017 15:07:56 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v52F7uRL030523; Fri, 2 Jun 2017 15:07:56 GMT From: David Ball To: Qin Wu , "l3sm@ietf.org" References: Message-ID: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> Date: Fri, 2 Jun 2017 16:07:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------15B4087B14A2EA534EBDFC2B" Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 15:08:08 -0000 This is a multi-part message in MIME format. --------------15B4087B14A2EA534EBDFC2B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm -- David Ball --------------15B4087B14A2EA534EBDFC2B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

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
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm


-- 
David Ball
<daviball@cisco.com>
--------------15B4087B14A2EA534EBDFC2B-- From nobody Wed Jun 7 21:11:55 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F098129B06 for ; Wed, 7 Jun 2017 21:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFTmEpq0pjcs for ; Wed, 7 Jun 2017 21:11:50 -0700 (PDT) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id 5A596129B05 for ; Wed, 7 Jun 2017 21:11:49 -0700 (PDT) Received: from LTMC2121.kddi.com (LTMC2121.kddi.com [10.206.0.61]) by post-send.kddi.com (KDDI Mail) with ESMTP id 71F3EE0075; Thu, 8 Jun 2017 13:11:47 +0900 (JST) Received: from LTMC2146.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2121.kddi.com with ESMTP; Thu, 8 Jun 2017 13:11:47 +0900 Received: from LTMC2146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 4AE4130005D; Thu, 8 Jun 2017 13:11:47 +0900 (JST) Received: from LTMC2151.kddi.com (post-incheck [10.206.0.239]) by LTMC2146.kddi.com (Postfix) with ESMTP id 3F81D300051; Thu, 8 Jun 2017 13:11:47 +0900 (JST) Received: from LTMC2151.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id v584BkDd010342; Thu, 8 Jun 2017 13:11:47 +0900 Received: from LTMC2151.kddi.com.mid_21302917 (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id v5841hKA047601; Thu, 8 Jun 2017 13:01:43 +0900 X-SA-MID: 21302917 Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Thu, 8 Jun 2017 13:01:42 +0900 From: "Ogaki, Kenichi" To: "'David Ball'" , "'Qin Wu'" , References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> In-Reply-To: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> Date: Thu, 8 Jun 2017 13:01:42 +0900 Message-ID: <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI8KJ/JrK2KyxsjaGJAhXNMm3Sl2gG6ddmroTnwHzA= Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 04:11:54 -0000 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:l3sm-bounces@ietf.org] On Behalf Of David Ball Sent: Saturday, June 03, 2017 12:08 AM To: Qin Wu; l3sm@ietf.org 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. 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? [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. 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 L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm -- David Ball From nobody Mon Jun 12 07:39:34 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9219912EAE4 for ; Mon, 12 Jun 2017 07:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XXd0nrtHWKH for ; Mon, 12 Jun 2017 07:39:28 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E478D129411 for ; Mon, 12 Jun 2017 07:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54200; q=dns/txt; s=iport; t=1497278368; x=1498487968; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=5JmEpTbtpzB06/BosUQ80MX2oA4GIpFiWsen+YqQoDE=; b=GRvnfiQ9g0A2E1exwFbYcr0/s++iKb/mtvciRpPqpzFsXQumkobVp5Ef vOnR8FFLlrRvqn86qJX+uGai5BIXKYVI6DswPscVIF3oo3priBvCjkVnY p4Jo9AyeSJo6s/bY8yMJG+nhA9dGCpNqiUUGwp5JKN1u3qB+O17dUgVp6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUAACGpj5Z/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqBDYN0ihhzkHuWA4IOAyEBCoV4AhqDFBgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEYAQhLEAcECxEEAQEBGAgBBgMCAgIlHwkIBgEMBgIBAReKCQgQr?= =?us-ascii?q?kYRgSOCJiuLOQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhmGBXwErgnWBPYJzFwM?= =?us-ascii?q?KLQ8GIoJEgmEFiUOGcoFdjC2TSYIGg0CCA4NLhnKML4g9HziBCjAhCBsVSIUMA?= =?us-ascii?q?QQHEIFlAj82hyCCPgEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,333,1493683200"; d="scan'208,217";a="653541671" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2017 14:39:24 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5CEdN38014429; Mon, 12 Jun 2017 14:39:23 GMT To: "Ogaki, Kenichi" , "'Qin Wu'" , l3sm@ietf.org References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> From: David Ball Message-ID: <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> Date: Mon, 12 Jun 2017 15:39:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> Content-Type: multipart/alternative; boundary="------------F4461172FD60014C70DBDC7F" Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 14:39:32 -0000 This is a multi-part message in MIME format. --------------F4461172FD60014C70DBDC7F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks Kenichi, please see further thoughs inline: On 08/06/2017 05:01, Ogaki, Kenichi wrote: > 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:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Saturday, June 03, 2017 12:08 AM > To: Qin Wu; l3sm@ietf.org > 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. [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. > 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. [DB] Ok - but what about my more general question? Is a single site always assumed to be topologically disconnected from other sites? > 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. [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. > 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. [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 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. [DB] So is there a reason it was not done that way? > 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. [DB] Qin, will you be fixing this in the bis version? > 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. [DB] Ok. > 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. [DB] Anyone else? It doesn't seem useful to have a leaf in the model if we don't know what it means... > 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. [DB]: Ok, yes I can see how implementing that might not be straightforward. > 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. [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? > 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. [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? > 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. [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? > 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? > > > [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. > 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. [DB] Ok. > 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. [DB] Ok. > 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. [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?) > 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. [DB] I think it would be useful to clarify it. Qin? > 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. [DB] Ok. > 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. [DB] Ok. > 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. [DB] Ok. > 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. [DB] Right, but for a P2P L2 technology, the IP nexthop doesn't need to be specified, 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. > > > [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? > 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. [DB] I guess given your other answers, this would be outside the scope of the model? > 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. [DB] Ok. > 4. For IPv6 connection, is there a case where only link-local addresses are used? > > [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 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. [DB] Qin, will you fix this? > 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. [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 > > > 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 > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm > > -- David Ball --------------F4461172FD60014C70DBDC7F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICA8cD5UaGFua3MgS2Vu aWNoaSwgcGxlYXNlIHNlZSBmdXJ0aGVyIHRob3VnaHMgaW5saW5lOjxicj4NCiAgICA8L3A+ DQogICAgPGJyPg0KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMDgvMDYv MjAxNyAwNTowMSwgT2dha2ksIEtlbmljaGkNCiAgICAgIHdyb3RlOjxicj4NCiAgICA8L2Rp dj4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOjAwZDMw MWQyZTAwYiRmMDIwMGNhMCRkMDYwMjVlMCRAa2RkaS5jb20iPg0KICAgICAgPHByZSB3cmFw PSIiPkhpIERhdmlkLA0KDQpBcyBhbiBhdXRob3IgYW5kIG9wZXJhdG9yLCBzZWUgY29tbWVu dHMgaW5saW5lLCBwbGVhc2UuDQpTdGVwaGFuZSwgbHVpcywgY291bGQgeW91IGNvcnJlY3Qg bWUgaWYgSSBtaXN1bmRlcnN0YW5kPw0KDQpUaGFua3MsDQpLZW5pY2hpDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMM3NtIFs8YSBjbGFzcz0ibW96LXR4dC1saW5r LWZyZWV0ZXh0IiBocmVmPSJtYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 bDNzbS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIERhdmlkIEJhbGwNClNl bnQ6IFNhdHVyZGF5LCBKdW5lIDAzLCAyMDE3IDEyOjA4IEFNDQpUbzogUWluIFd1OyA8YSBj bGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86bDNzbUBpZXRm Lm9yZyI+bDNzbUBpZXRmLm9yZzwvYT4NClN1YmplY3Q6IFJlOiBbTDNzbV0gTmV4dCBTdGVw IG9mIFJGQzgwNDkNCg0KSGkgUWluLA0KDQoNCkFzIHlvdSBhcmUgd29ya2luZyBvbiBhIGJp cyB2ZXJzaW9uLCBJIGhhdmUgYSBmZXcgcXVlc3Rpb25zIG9uIFJGQzgwNDkgdGhhdCBtaWdo dCBsZWFkIHRvIGRpc2N1c3Npb24gb24gdGhlIGxpc3QsIGFuZCBwZXJoYXBzIHNvbWUgZnVy dGhlciBjaGFuZ2VzLg0KDQoNCjEuCVRoZSBzY29wZSBvZiB0aGUgUkZDIHNlZW1zIHRvIGJl IGZvY3VzZWQgb24gaW5mb3JtYXRpb24gdGhhdCBuZWVkcyB0byBiZSBwYXNzZWQgZnJvbSB0 aGUgY3VzdG9tZXIgdG8gdGhlIFNQIChlLmcuIGluIGEgInJlcXVlc3QiKTsgaG93ZXZlciwg Y2xlYXJseSBmb3IgdGhlIGN1c3RvbWVyIHRvIGJlIGFibGUgdG8gdXNlIHRoZSBzZXJ2aWNl LCB0aGVyZSBpcyBhbHNvIGluZm9ybWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgcGFzc2VkIGJh Y2sgZnJvbSB0aGUgU1AgdG8gdGhlIGN1c3RvbWVyLiAgSXQgc2VlbXMgdGhhdCB0aGUgbW9k ZWwgaXMgbm90IGludGVuZGVkIHRvIGNvdmVyIHRoYXQgLSBpcyB0aGF0IHJpZ2h0PyAgSSB0 aGluayB0aGF0J3MgZmluZSwgYnV0IGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gbWFrZSB0aGlz IGNsZWFyZXIgKHBlcmhhcHMgaW4gc2VjdGlvbiA1PykNCg0KW0tPXSBUaGF0J3MgcmlnaHQu PC9wcmU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICA8Zm9udCBjb2xvcj0i IzAwMDA5OSI+W0RCXTogT2ssIHRoYW5rcy7CoCBRaW4sIGlmIHlvdSBhcmUgZGV2ZWxvcGlu Zw0KICAgICAgYSBiaXMgdmVyc2lvbiwgaXQgd291bGQgZGVmaW5pdGVseSBoZWxwIHRvIG1h a2UgdGhpcyBjbGVhcmVyIG5lYXINCiAgICAgIHRoZSBzdGFydCBvZiB0aGUgZG9jLjxicj4N CiAgICA8L2ZvbnQ+PGJyPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQogICAgICBj aXRlPSJtaWQ6MDBkMzAxZDJlMDBiJGYwMjAwY2EwJGQwNjAyNWUwJEBrZGRpLmNvbSI+DQog ICAgICA8cHJlIHdyYXA9IiI+Mi4JSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSBj b25jZXB0IG9mIGEgInNpdGUiLiAgSW4gdGhlIHNpbXBsZXN0IGNhc2UsIGl0IHNlZW1zIGNs ZWFyIHRoYXQgdGhpcyBtZWFucyBhIHNpbmdsZSBwaHlzaWNhbCBsb2NhdGlvbiwgd2l0aCBv bmUgb3IgbW9yZSBjb25uZWN0aW9ucyAoc2l0ZSBuZXR3b3JrIGFjY2Vzc2VzKSB0byB0aGUg U1AuICBUaGUgUkZDIGFsc28gZGVzY3JpYmVzIGEgY2FzZSB3aGVyZSBhIHNpbmdsZSAic2l0 ZSIgY291bGQgYmUgaW4gbXVsdGlwbGUgbG9jYXRpb25zIHRoYXQgYXJlIGludGVyY29ubmVj dGVkIGluZGVwZW5kZW50bHkgb2YgdGhlIFZQTiBzZXJ2aWNlIC0gdGhlIGV4YW1wbGUgZ2l2 ZW4gaXMgbXVsdGlwbGUgb2ZmaWNlcyBpbiB0aGUgc2FtZSBjaXR5LiAgRG9lcyB0aGlzIGV4 dGVuZCBtb3JlIGdlbmVyYWxseT8gIEUuZy4sIGlmIHR3byBsb2NhdGlvbnMgaW4gZGlmZmVy ZW50IGNpdGllcyBhcmUgY29ubmVjdGVkIGJ5IGEgYmFja2Rvb3IgbGluaywgZG9lcyB0aGF0 IG1lYW4gdGhleSdyZSB0aGUgc2FtZSBzaXRlPyAgV2hhdCBhYm91dCBpZiB0aGUgYmFja2Rv b3IgbGluayBpcyBvbmx5IHVzZWQgZm9yIGJhY2t1cCAoaS5lLiB3aGVuIGNvbm5lY3Rpdml0 eSB2aWEgdGhlIFZQTiBpcyBkb3duKT8gIElzIGEgInNpdGUiIGFsd2F5cyBjb21wbGV0ZWx5 IGRpc2Nvbm5lY3RlZCAodG9wb2xvZ2ljYWxseSkgZnJvbSBvdGhlciBzaXRlcyAob3RoZXIg dGhhbiB2aWEgdGhlIFZQTiBzZXJ2aWNlKT8NCg0KW0tPXSBUaGlzIGNhc2Ugb2YgdGhlIGJh Y2tkb29yIGlzIGEgY29ybmVyIGNhc2UgYW5kIGEgc2VydmljZSBtb2RlbCBzaG91bGQgbm90 IGRlZmluZSBzdWNoIGNvcm5lciBjYXNlcy48L3ByZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQog ICAgPGJyPg0KICAgIDxmb250IGNvbG9yPSIjMDAwMDk5Ij5bREJdIE9rIC0gYnV0IHdoYXQg YWJvdXQgbXkgbW9yZSBnZW5lcmFsDQogICAgICBxdWVzdGlvbj/CoCBJcyBhIHNpbmdsZSBz aXRlIGFsd2F5cyBhc3N1bWVkIHRvIGJlIHRvcG9sb2dpY2FsbHkNCiAgICAgIGRpc2Nvbm5l Y3RlZCBmcm9tIG90aGVyIHNpdGVzPzwvZm9udD48YnI+DQogICAgPGJyPg0KICAgIDxibG9j a3F1b3RlIHR5cGU9ImNpdGUiDQogICAgICBjaXRlPSJtaWQ6MDBkMzAxZDJlMDBiJGYwMjAw Y2EwJGQwNjAyNWUwJEBrZGRpLmNvbSI+DQogICAgICA8cHJlIHdyYXA9IiI+My4JU29tZXdo YXQgcmVsYXRlZCwgSSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5jZSBi ZXR3ZWVuIGEgc2l0ZSB3aXRoIHN1Yi1WUE5zIChpLmUuIGVhY2ggc2l0ZS1hY2Nlc3MtbGlu ayBpcyBjb25uZWN0ZWQgdG8gYSBkaWZmZXJlbnQgVlBOKSB2cyB0cmVhdGluZyBpdCBhcyB0 d28gc2l0ZXMsIGVhY2ggd2l0aCBhIHNpbmdsZSBzaXRlLWFjY2Vzcy1saW5rLiAgVGhlIHRl eHQgc2F5cyBhIHN1Yi1WUE4gImlzIHNpbWlsYXIgdG8gaGF2aW5nIHNlcGFyYXRlIHNpdGVz LCBidXQgaW4gdGhpcyBjYXNlIHRoZSBjdXN0b21lciB3YW50cyB0byBzaGFyZSBzb21lIHBo eXNpY2FsIGNvbXBvbmVudHMgd2hpbGUgbWFpbnRhaW5pbmcgc3Ryb25nIGNvbW11bmljYXRp b24gaXNvbGF0aW9uIi4gIERvZXMgInRoaXMgY2FzZSIgbWVhbiB0aGUgc3ViLVZQTiBjYXNl IG9yIHRoZSBtdWx0aXBsZSBzaXRlcyBjYXNlPyAgRWl0aGVyIHdheSwgdGhlIGN1c3RvbWVy IGNvdWxkIHNoYXJlIHBoeXNpY2FsIGNvbXBvbmVudHMgYW5kIG1haW50YWluIHN0cm9uZyBp c29sYXRpb24sIHJpZ2h0Pw0KDQpbS09dIFRoaXMgY2FzZSBtZWFucyB0aGUgc3ViLVZQTiBj YXNlLCBhbmQgeW91ciBpbmRpY2F0aW9uIGlzIHJpZ2h0LjwvcHJlPg0KICAgIDwvYmxvY2tx dW90ZT4NCiAgICA8YnI+DQogICAgPGZvbnQgY29sb3I9IiMwMDAwOTkiPltEQl0uwqAgT2sg LSBpZiBpdCB0aGUgc2FtZSBhcyB1c2luZyBtdWx0aXBsZQ0KICAgICAgc2l0ZXMgKHdoaWNo IHdvdWxkIHN0aWxsIGJlIHRvcG9sb2dpY2FsbHkgc2VwYXJhdGUgZXZlbiBpZiB0aGV5DQog ICAgICB1c2UgdGhlIHNhbWUgcGh5c2ljYWwgY29tcG9uZW50cyksIEkgZ3Vlc3MgSSBkb24n dCB1bmRlcnN0YW5kIHRoZQ0KICAgICAgcHVycG9zZSBvZiBoYXZpbmcgc3ViLVZQTiBhcyBh biBvcHRpb24gLSBidXQgZ29vZCB0byBrbm93IHRoZXJlIGlzDQogICAgICBub3RoaW5nIGV4 dHJhIEknbSBtaXNzaW5nIGhlcmUuPC9mb250Pjxicj4NCiAgICA8YnI+DQogICAgPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSINCiAgICAgIGNpdGU9Im1pZDowMGQzMDFkMmUwMGIkZjAyMDBj YTAkZDA2MDI1ZTAkQGtkZGkuY29tIj4NCiAgICAgIDxwcmUgd3JhcD0iIj40LglVbmRlciB0 aGUgVlBOIHNlcnZpY2UsIHRoZXJlIGlzIGEgbGVhZiBmb3IgdGhlIGN1c3RvbWVyIG5hbWUu ICBJZiB0aGUgbW9kZWwgaXMgc3VwcG9zZWQgdG8gcmVwcmVzZW50IHRoZSByZXF1ZXN0IGZy b20gYSBjdXN0b21lciB0byB0aGUgU1AsIEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoZSBjdXN0 b21lciBuYW1lIHdvdWxkIGJlIGtub3duIG91dC1vZi1iYW5kLCBlLmcuIGZyb20gdGhlIEFB QSBmb3IgdGhlIHJlcXVlc3Q/ICBJdCB3b3VsZCBiZSBiYWQgaWYgb25lIGN1c3RvbWVyIGNv dWxkIHJlcXVlc3QgdGhpbmdzIGZvciBhbm90aGVyIGN1c3RvbWVyIGJ5IGZpbGxpbmcgaW4g YSBkaWZmZXJlbnQgY3VzdG9tZXIgbmFtZSBpbiB0aGUgbW9kZWwhICANCgkNCltLT10gQSBj dXN0b21lciBjYW4gb25seSBhY2Nlc3MgdGhlIG1vZGVsIGluc3RhbmNlIG9mIHRoYXQgY3Vz dG9tZXIuIFBsZWFzZSBzZWUgc2VjdGlvbiAxMC48L3ByZT4NCiAgICA8L2Jsb2NrcXVvdGU+ DQogICAgPGJyPg0KICAgIDxmb250IGNvbG9yPSIjMDAwMDk5Ij5bREJdIFllcyBleGFjdGx5 IC0gaWYgYSBjdXN0b21lciBjYW4gb25seQ0KICAgICAgYWNjZXNzIHRoZWlyIG93biBpbnN0 YW5jZSBvZiB0aGUgbW9kZWwsIHdoeSBkb2VzIHRoZSBjdXN0b21lciBuYW1lDQogICAgICBu ZWVkIHRvIGJlIHNwZWNpZmllZCB3aXRoaW4gdGhlIG1vZGVsP8KgIFlvdSBhbHJlYWR5IGtu b3cgeW91IGFyZQ0KICAgICAgZGVhbGluZyB3aXRoIHRoYXQgY3VzdG9tZXIncyBpbnN0YW5j ZSBvZiB0aGUgbW9kZWwuwqAgSXQgc2VlbXMgbGlrZQ0KICAgICAgdGhlIGN1c3RvbWVyLW5h bWUgbGVhZiBpcyB1bm5lY2Vzc2FyeT88L2ZvbnQ+PGJyPg0KICAgIDxicj4NCiAgICA8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOjAwZDMwMWQyZTAwYiRmMDIw MGNhMCRkMDYwMjVlMCRAa2RkaS5jb20iPg0KICAgICAgPHByZSB3cmFwPSIiPjUuCUZvciBj bG91ZCBhY2Nlc3MsIGEgc2luZ2xlIFZQTiBjYW4gY29ubmVjdCB0byBtdWx0aXBsZSBjbG91 ZCBzZXJ2aWNlcywgYW5kIGZvciBlYWNoIGNsb3VkIHNlcnZpY2UgeW91IGhhdmUgdG8gc3Bl Y2lmeSB3aGljaCBzaXRlcyBhcmUgYXV0aG9yaXplZCB0byBhY2Nlc3MgdGhlIGNsb3VkLiAg SXMgdGhlcmUgYSByZWFzb24gaXQgd2FzIG1vZGVsbGVkIHRoaXMgd2F5LCByYXRoZXIgdGhh biBoYXZpbmcgYSBzZXBhcmF0ZSBWUE4gc2VydmljZSB0byBjb25uZWN0IHRvIGVhY2ggY2xv dWQgc2VydmljZT8gIElmIHRoZXJlIHdhcyBhIHNlcGFyYXRlIFZQTiBzZXJ2aWNlIGZvciBl YWNoIGNsb3VkIHNlcnZpY2UsIHRoZW4gb25seSB0aGUgcmlnaHQgc2l0ZXMgd291bGQgYmUg YXR0YWNoZWQgdG8gdGhlIFZQTiBmb3IgZWFjaCBjbG91ZCwgYW5kIGl0IHdvdWxkIG5vdCBi ZSBuZWNlc3NhcnkgdG8gaGF2ZSBhIHNlcGFyYXRlIGxpc3Qgb2YgYXV0aG9yaXplZCBzaXRl cywgcmlnaHQ/DQoJDQpbS09dIFRoYXQncyByaWdodC48L3ByZT4NCiAgICA8L2Jsb2NrcXVv dGU+DQogICAgPGZvbnQgY29sb3I9IiMwMDAwOTkiPjxicj4NCiAgICAgIFtEQl0gU28gaXMg dGhlcmUgYSByZWFzb24gaXQgd2FzIG5vdCBkb25lIHRoYXQgd2F5PzwvZm9udD48YnI+DQog ICAgPGJyPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQogICAgICBjaXRlPSJtaWQ6 MDBkMzAxZDJlMDBiJGYwMjAwY2EwJGQwNjAyNWUwJEBrZGRpLmNvbSI+DQogICAgICA8cHJl IHdyYXA9IiI+Ni4JT24gdGhhdCBzdWJqZWN0LCB0aGUgeWFuZyBtb2R1bGUgaGFzIC9sM3Zw bi1zdmMvdnBuLXNlcnZpY2VzL3Zwbi1zZXJ2aWNlL2Nsb3VkLWFjY2Vzc2VzL2Nsb3VkLWFj Y2Vzcy9saXN0LWZsYXZvciwgd2hpY2ggaXMgYSBjaG9pY2Ugb2YgcGVybWl0LWFueSwgcGVy bWl0LWFueS1leGNlcHQgYW5kIGRlbnktYW55LWV4Y2VwdC4gIEl0IGFsc28gaGFzIC9sM3Zw bi1zdmMvdnBuLXNlcnZpY2VzL3Zwbi1zZXJ2aWNlL2Nsb3VkLWFjY2Vzc2VzL2Nsb3VkLWFj Y2Vzcy9hdXRob3JpemVkLXNpdGVzIGFuZCAvbDN2cG4tc3ZjL3Zwbi1zZXJ2aWNlcy92cG4t c2VydmljZS9jbG91ZC1hY2Nlc3Nlcy9jbG91ZC1hY2Nlc3MvZGVuaWVkLXNpdGVzLCB3aGlj aCBzZWVtIHRvIHNlcnZlIHRoZSBzYW1lIHB1cnBvc2UuICBUaGlzIGxvb2tzIGxpa2UgYW4g ZXJyb3IgLSB3YXMgb25lIG9mIHRoZXNlIHN1cHBvc2VkIHRvIGJlIGRlbGV0ZWQ/ICBJZiBu b3QsIHdoYXQgaXMgdGhlIGRpZmZlcmVuY2U/ICBJIG5vdGljZWQgdGhhdCBzZWN0aW9uIDYu Mi4yIG9ubHkgbWVudGlvbnMgdGhlIGZpcnN0IG9uZSAobGlzdC1mbGF2b3IvLi4uKS4NCg0K DQpbS09dIEkgdGhpbmsgeW91IGFyZSByaWdodC4gZGVueS1hbnktZXhjZXB0IGxvb2tzIHNh bWUgYXMgYXV0aG9yaXplZC1zaXRlcywgYW5kIHBlcm1pdC1hbnktZXhjZXB0IGRvZXMgZGVu aWVkLXNpdGVzLg0KPC9wcmU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICA8 Zm9udCBjb2xvcj0iIzAwMDA5OSI+W0RCXSBRaW4sIHdpbGwgeW91IGJlIGZpeGluZyB0aGlz IGluIHRoZSBiaXMNCiAgICAgIHZlcnNpb24/PGJyPg0KICAgIDwvZm9udD48YnI+DQogICAg PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCiAgICAgIGNpdGU9Im1pZDowMGQzMDFkMmUwMGIk ZjAyMDBjYTAkZDA2MDI1ZTAkQGtkZGkuY29tIj4NCiAgICAgIDxwcmUgd3JhcD0iIj43LglT dGlja2luZyB3aXRoIGNsb3VkIGFjY2VzcywgdGhlcmUgaXMgYW4gb3B0aW9uIGZvciBlbmFi bGluZyBOQVQ0NC4gIEhvd2V2ZXIsIG9ubHkgYSBzaW5nbGUgYWRkcmVzcyBjYW4gYmUgc3Bl Y2lmaWVkLiAgRm9yIHNvbWUgYmlnIGVudGVycHJpc2UgY3VzdG9tZXJzLCB3aGVuIE5BVCBp cyB1c2VkLCBtb3JlIHRoYW4gb25lIHB1YmxpYy1mYWNpbmcgYWRkcmVzcyBpcyBuZWVkZWQg KHR5cGljYWxseSBmcm9tIHRoZSBzYW1lIElQIHByZWZpeCkgLSBpcyB0aGVyZSBhIHdheSB0 byBhY2NvbW1vZGF0ZSB0aGF0IGNhc2U/DQoNCltLT10gVGhlIGN1cnJlbnQgbW9kZWwgY2Fu IGNvdmVyIHRoZSBjYXNlLiBTUCBqdXN0IGhhcyB0byBwaWNrIGEgcmFuZ2Ugb2YgYWRkcmVz c2VzLCBidXQgc29tZSBhdWdtZW50YXRpb25zLCBob3cgbWFueSBhZGRyZXNzZXMgYXJlIHJl cXVpcmVkLCBpcyBkZXNpcmVkLjwvcHJlPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8Zm9u dCBjb2xvcj0iIzAwMDA5OSI+PGJyPg0KICAgICAgW0RCXSBPay48YnI+DQogICAgICA8YnI+ DQogICAgPC9mb250Pg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQogICAgICBjaXRl PSJtaWQ6MDBkMzAxZDJlMDBiJGYwMjAwY2EwJGQwNjAyNWUwJEBrZGRpLmNvbSI+DQogICAg ICA8cHJlIHdyYXA9IiI+OC4JVGhlcmUgaXMgYSAnc3ZjLW10dScgbGVhZiB1bmRlciB0aGUg c2l0ZS1uZXR3b3JrLWFjY2VzczsgaG93ZXZlciwgaXQncyBub3QgbWVudGlvbmVkIGluIHNl Y3Rpb24gNiBhbmQgaXQncyBub3QgY2xlYXIgaG93IGl0J3MgaW50ZW5kZWQgdG8gYmUgdXNl ZC4gIEF0IGxlYXN0IGZvciBJUHY0LCBwYWNrZXRzIGxhcmdlciB0aGFuIHRoZSBNVFUgY2Fu IGJlIGZyYWdtZW50ZWQgKGFsdGhvdWdoIHRoYXQgbWlnaHQgYmUgdW5kZXNpcmFibGUsIHNv IGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBoYXZlIGEgcGVyLVZQTiBrbm9iIHRvIGRpc2FibGUg aXQpLiAgSSB0aGluayB0aGUgbWluaW11bSByZXF1aXJlbWVudCBpcyB0aGF0IHRoZSBjdXN0 b21lciBhbmQgdGhlIFNQIGFncmVlIG9uIHRoZSBsb3dlc3QgTVRVIGFjcm9zcyB0aGUgd2hv bGUgVlBOLCBzbyB0aGF0IHRoZSBjdXN0b21lciBjYW4gYmUgY2VydGFpbiB0aGF0IHBhY2tl dHMgc2hvcnRlciB0aGFuIHRoYXQgd2lsbCBiZSBkZWxpdmVyZWQuICBPZiBjb3Vyc2UsIHRo ZSBjdXN0b21lciBtaWdodCB1c2UgdGVjaG5pcXVlcyBsaWtlIHBhdGggTVRVIGRpc2NvdmVy eSB0byBkZXRlcm1pbmUgdGhhdCB0aGV5IGNhbiB1c2UgYSBsYXJnZXIgTVRVIGZvciBwYXJ0 aWN1bGFyIHBhdGhzLiAgSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBzb21l IGRpc2N1c3Npb24gb2YgdGhpcyB0b3BpYyBpbiB0aGUgUkZDLg0KDQpbS09dIFRoaXMgbGVh ZiBpcyByZXF1aXJlZCB0byBiZSBzZXQgdGhlIHZhbHVlIGlmIGEgY3VzdG9tZXIgcmVxdWly ZXMgdG8gZG8gc28uIEJ1dCwgSSBoYXZlIG5vIGlkZWEgYWJvdXQgdGhlIGNhc2UuPC9wcmU+ DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICA8Zm9udCBjb2xvcj0iIzAwMDA5 OSI+W0RCXSBBbnlvbmUgZWxzZT/CoCBJdCBkb2Vzbid0IHNlZW0gdXNlZnVsIHRvDQogICAg ICBoYXZlIGEgbGVhZiBpbiB0aGUgbW9kZWwgaWYgd2UgZG9uJ3Qga25vdyB3aGF0IGl0IG1l YW5zLi4uPC9mb250Pjxicj4NCiAgICA8YnI+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSINCiAgICAgIGNpdGU9Im1pZDowMGQzMDFkMmUwMGIkZjAyMDBjYTAkZDA2MDI1ZTAkQGtk ZGkuY29tIj4NCiAgICAgIDxwcmUgd3JhcD0iIj45LglUaGVyZSBpcyBhIHBlci1zaXRlIGxp bWl0IG9uIHRoZSBudW1iZXIgb2YgIElQdjQvSVB2NiByb3V0ZXMgKCJtYXhpbXVtLXJvdXRl cyIpIC0gaXMgdGhpcyB0aGUgbWF4aW11bSBudW1iZXIgb2Ygcm91dGVzIHRoYXQgY2FuIGJl IGFkdmVydGlzZWQgYnkgdGhlIGN1c3RvbWVyIHRvd2FyZHMgdGhlIFNQIGF0IHRoYXQgc2l0 ZT8gIEluIGEgbXVsdGktVlBOIGNhc2UsIHdvdWxkIGl0IGJlIHVzZWZ1bCB0byBoYXZlIGEg cGVyLXNpdGUsIHBlci1WUE4gbGltaXQsIGUuZy4gaW4gdGhlIGNhc2Ugd2hlcmUgb25lIG9m IHRoZSBWUE5zIGlzIGFuIGV4dHJhbmV0LCB0byBsaW1pdCB0aGUgbnVtYmVyIG9mIHByZWZp eGVzIHRoYXQgY2FuIGJlIGFkdmVydGlzZWQgaW50byB0aGUgZXh0cmFuZXQgYXQgdGhhdCBz aXRlPw0KCQ0KW0tPXSBJdCBtYXkgYmUgdXNlZnVsLCBidXQgYSBzb2x1dGlvbiBpcyByZXF1 aXJlZCwgYW5kIEkgZG9uJ3Qga25vdyBzdWNoIGFuIGV4aXN0aW5nIHNvbHV0aW9uLjwvcHJl Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+DQogICAgPGZvbnQgY29sb3I9IiMwMDAw OTkiPltEQl06IE9rLCB5ZXMgSSBjYW4gc2VlIGhvdyBpbXBsZW1lbnRpbmcgdGhhdA0KICAg ICAgbWlnaHQgbm90IGJlIHN0cmFpZ2h0Zm9yd2FyZC48L2ZvbnQ+PGJyPg0KICAgIDxicj4N CiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOjAwZDMwMWQy ZTAwYiRmMDIwMGNhMCRkMDYwMjVlMCRAa2RkaS5jb20iPg0KICAgICAgPHByZSB3cmFwPSIi PjEwLglUaGVyZSBpcyBhIHFvcy1jbGFzc2lmaWNhdGlvbi1wb2xpY3kgKGVpdGhlciBwZXIt c2l0ZSBvciBwZXItc2l0ZS1uZXR3b3JrLWFjY2VzcyksIHdoaWNoIGRlc2NyaWJlcyBob3cg dG8gbWFwIHBhY2tldHMgdG8gdGhlIHJpZ2h0IGNsYXNzIG9mIHNlcnZpY2UuICBJbiBhIHNp bmdsZS1WUE4gY2FzZSwgdGhpcyBpcyBmaW5lLCBidXQgSSBhbSBub3Qgc3VyZSBob3cgdG8g aW50ZXJwcmV0IGl0IHdoZW4gdGhlIHNpdGUgaXMgYXR0YWNoZWQgdG8gbXVsdGlwbGUgVlBO cy4gIFRoZSBkaWZmZXJlbnQgVlBOcyBtaWdodCBoYXZlIGRpZmZlcmVudCBjbGFzc2VzIG9m IHNlcnZpY2UsIHNvIGRvZXNuJ3QgdGhlIGNsYXNzaWZpY2F0aW9uIHBvbGljeSBuZWVkIHRv IGJlIHBlci1zaXRlIHBlci1WUE4sIG5vdCBqdXN0IHBlci1zaXRlPw0KDQpbS09dIEFzIGRl c2NyaWJlZCBpbiA2LjEyLjIuMSwgd2hlcmUgdG8gY2xhc3NpZnkgYW5kIGFwcGx5IHRoZSBx b3MgaXMgdXAgdG8gdGhlIFNQLCBhbmQgb3V0c2lkZSBvZiBzY29wZSBvZiB0aGlzIG1vZGVs LjwvcHJlPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+DQogICAgPGZvbnQgY29sb3I9 IiMwMDAwOTkiPltEQl0gQWdyZWVkLCBidXQgdGhhdCB3YXNuJ3QgbXkgcXVlc3Rpb24uwqAg VGhlDQogICAgICBxdWVzdGlvbiBpcywgaW4gYSBtdWx0aS1WUE4gY2FzZSwgZG9uJ3QgeW91 IHdhbnQgYSBkaWZmZXJlbnQgUW9TDQogICAgICBwb2xpY3kgZm9yIGVhY2ggVlBOIGF0IHRo ZSBzaXRlPzwvZm9udD48YnI+DQogICAgPGJyPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNp dGUiDQogICAgICBjaXRlPSJtaWQ6MDBkMzAxZDJlMDBiJGYwMjAwY2EwJGQwNjAyNWUwJEBr ZGRpLmNvbSI+DQogICAgICA8cHJlIHdyYXA9IiI+MTEuCVRoZSByZWxhdGVkIHFvcy1wcm9m aWxlIGhhcyBjb25zdHJhaW50cyBvbiBsYXRlbmN5IGFuZCBqaXR0ZXI7IGhvd2V2ZXIsIHRo ZXNlIGFwcGx5IHRvIGFsbCBwYWNrZXRzIGluIGEgZmxvdy4gIFNvLCBmb3IgZXhhbXBsZSwg aWYgdGhlcmUgd2VyZSBzaXRlcyBpbiBMb25kb24sIFBhcmlzIGFuZCBTYW4gRnJhbmNpc2Nv LCB0aGUgc2FtZSBsYXRlbmN5IGNvbnN0cmFpbnQgd291bGQgYXBwbHkgdG8gcGFja2V0cyBm cm9tIExvbmRvbiB0byBQYXJpcyBhbmQgcGFja2V0cyBmcm9tIExvbmRvbiB0byBTYW4gRnJh bmNpc2NvLCB3aGljaCBkb2Vzbid0IHNlZW0gdmVyeSB1c2VmdWwuICBTaW1pbGFybHksIGlu IGEgbXVsdGktVlBOIGNhc2UsIHRoZSBzYW1lIGNvbnN0cmFpbnRzIHdvdWxkIGFwcGx5IHJl Z2FyZGxlc3Mgb2Ygd2hpY2ggVlBOIHRoZSBwYWNrZXQgbWFwcyB0by4gIFRoaXMgdHlwZSBv ZiBjb25zdHJhaW50IHdvdWxkIG5vcm1hbGx5IGJlIGluIGFuIFNMUywgYnV0IEkgdGhvdWdo dCBpbiBnZW5lcmFsIHRoZSBhcHByb2FjaCB3YXMgdG8gYXZvaWQgdHJ5aW5nIHRvIHNwZWNp ZnkgYW4gU0xTIGluIHRoZSBtb2RlbD8gDQoJDQpbS09dIFNhbWUgY29tbWVudCBhcyBhYm92 ZS4gQW5kLCBJIGFncmVlIHdpdGggeW91ciB0aG91Z2h0IGFib3V0IHRoZSBTTFMuPC9wcmU+ DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICA8Zm9udCBjb2xvcj0iIzAwMDA5 OSI+W0RCXSBPay7CoCBJIGRvbid0IGtub3cgd2hlbiB0aGlzIHdhcyBhZGRlZCwgSQ0KICAg ICAgZG9uJ3QgcmVtZW1iZXIgc2VlaW5nIGl0IGluIHRoZSBkcmFmdHMgSSBsb29rZWQgYXQg YXQgdGhlIHRpbWUuwqANCiAgICAgIERvIHlvdSB0aGluayBpdCBzaG91bGQgYmUgcmVtb3Zl ZCBpbiBRaW4ncyBiaXMgdmVyc2lvbj88L2ZvbnQ+PGJyPg0KICAgIDxicj4NCiAgICA8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOjAwZDMwMWQyZTAwYiRmMDIw MGNhMCRkMDYwMjVlMCRAa2RkaS5jb20iPg0KICAgICAgPHByZSB3cmFwPSIiPjEyLglPbiBz aW1pbGFyIGxpbmVzLCBpbiB0aGUgcW9zLXByb2ZpbGUgdGhlcmUgaXMgYSBndWFyYW50ZWVk LWJhbmR3aWR0aCwgd2hpY2ggY2FuIGVpdGhlciBiZSBmb3IganVzdCB0aGUgYWNjZXNzLCBv ciBjYW4gYmUgZW5kLXRvLWVuZC4gIEhvdyBzaG91bGQgYW4gZW5kLXRvLWVuZCBiYW5kd2lk dGggZ3VhcmFudGVlIGJlIGludGVycHJldGVkIGlmIHRoZSBWUE4gaGFzIG1vcmUgdGhhbiB0 d28gc2l0ZXM/ICBPciBkb2VzIGl0IG9ubHkgbWFrZSBzZW5zZSBmb3IgYSBQMlAgY2FzZT8N CgkNCltLT10gU2FtZSBjb21tZW50IGFzIGFib3ZlLiBBcyBJIGtub3csIGEgU1AgY29udHJv bHMgdGhlIGJhbmR3aWR0aCBhdCBpbnB1dC9vdXRwdXQgb2YgUEUuPC9wcmU+DQogICAgPC9i bG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICA8Zm9udCBjb2xvcj0iIzAwMDA5OSI+W0RCXSBB Z3JlZWQgLSBidXQgYWdhaW4sIHRoZSBxdWVzdGlvbiBpcyBhYm91dA0KICAgICAgdGhlIG1l YW5pbmcgb2YgdGhlIGF0dHJpYnV0ZSByYXRoZXIgdGhhbiB3aGVyZSB0aGUgU1AgaW1wbGVt ZW50cw0KICAgICAgaXQuwqAgSW4gYSBWUE4gd2l0aCAxMCBzaXRlcywgd2hhdCBkb2VzIGl0 IG1lYW4gdG8gc2F5IHRoYXQgdGhlDQogICAgICBlbmQtdG8tZW5kIGJhbmR3aWR0aCBpcyAx ME1iL3M/PC9mb250Pjxicj4NCiAgICA8YnI+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSINCiAgICAgIGNpdGU9Im1pZDowMGQzMDFkMmUwMGIkZjAyMDBjYTAkZDA2MDI1ZTAkQGtk ZGkuY29tIj4NCiAgICAgIDxwcmUgd3JhcD0iIj4xMy4JTG90cyBvZiBxdWVzdGlvbnMgYWJv dXQgdGhlIHJvdXRpbmctcHJvdG9jb2xzOg0KDQoJMS4JV2hlbiB0aGUgcm91dGluZyBwcm90 b2NvbCBpcyAiZGlyZWN0IiwgdGhlIFNQIHJvdXRlcyB0cmFmZmljIHRvd2FyZHMgdGhlIHBy ZWZpeCBzcGVjaWZpZWQgYnkgdGhlIGNvbm5lY3Rpb24gYWRkcmVzczsgaG93ZXZlciwgb25l IHdvdWxkIGV4cGVjdCB0aGF0IHRoZXkgYWx3YXlzIGRvIHRoaXMgcmVnYXJkbGVzcyBvZiB3 aGF0IG90aGVyIHJvdXRpbmcgcHJvdG9jb2wgaXMgaW4gdXNlLCByaWdodD8gIFNvLCB3aGF0 IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gc3BlY2lmeWluZyByb3V0aW5nIHByb3RvY29s ICJkaXJlY3QiLCBhbmQgbGVhdmluZyB0aGUgcm91dGluZyBwcm90Y29sIGxpc3QgZW1wdHk/ DQoNCg0KW0tPXSBUaGUgbGlzdCByb3V0aW5nLXByb3RvY29sIGhhcyB0aGUgZW50aXR5IHdp dGggInR5cGUiIGFzIHRoZSBrZXkuIFRoZW4gZW1wdHkgcm91dGluZyBwcm90b2NvbCBpcyBu b3QgYWxsb3dlZC48L3ByZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGZvbnQgY29sb3I9 IiMwMDAwOTkiPjxicj4NCiAgICAgIFtEQl0gSSBtZWFudCBhbiBlbXB0eSBsaXN0LCBub3Qg YW4gZW1wdHkgZWxlbWVudCBpbiB0aGUgbGlzdC7CoA0KICAgICAgVGhlcmUgaXMgbm8gIm1p bi1lbGVtZW50cyIgb24gdGhlIHJvdXRpbmctcHJvdG9jb2wgbGlzdCwgc28gdGhlDQogICAg ICBsaXN0IGl0c2VsZiBjb3VsZCBiZSBlbXB0eS48L2ZvbnQ+PGJyPg0KICAgIDxicj4NCiAg ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOjAwZDMwMWQyZTAw YiRmMDIwMGNhMCRkMDYwMjVlMCRAa2RkaS5jb20iPg0KICAgICAgPHByZSB3cmFwPSIiPgky LglUaGUgcHVycG9zZSBvZiBWUlJQIGlzIHRvIGJlIG9wYXF1ZSB0byB0aGUgY3VzdG9tZXIg LSBzbyBpdCdzIG5vdCBjbGVhciB3aHkgdGhlIGN1c3RvbWVyIHdvdWxkIGV4cGxpY2l0bHkg cmVxdWVzdCB0aGlzPyAgSXMgdGhlIGludGVudCB0byBjYXB0dXJlIHRoYXQgdGhlIGN1c3Rv bWVyIHdhbnRzIHRvIGVuc3VyZSB0aGVyZSBpcyByZWR1bmRhbmN5IG9mIHRoZSBhY2Nlc3Mg bGluayBhdCBMMj8gSWYgc28sIHBlcmhhcHMgaXQgd291bGQgYmUgYmV0dGVyIGhhbmRsZWQg YnkgaGF2aW5nIHNvbWUgc29ydCBvZiBhY2Nlc3MgY29uc3RyYWludCBmb3IgImwyLWRpdmVy c2UiPw0KCQkNCltLT10gRnJvbSBhbiBvcGVyYXRvcidzIHBlcnNwZWN0aXZlLCBWUlJQIGhh cyBjb21tb24gY29uc2Vuc3VzIGZvciBMM1ZQTiBjdXN0b21lcnMgcmF0aGVyIHRoYW4gd2hh dCBsMi1kaXZlcnNlIG1lYW5zLjwvcHJlPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+ DQogICAgPGZvbnQgY29sb3I9IiMwMDAwOTkiPltEQl0gT2suPC9mb250Pjxicj4NCiAgICA8 YnI+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCiAgICAgIGNpdGU9Im1pZDowMGQz MDFkMmUwMGIkZjAyMDBjYTAkZDA2MDI1ZTAkQGtkZGkuY29tIj4NCiAgICAgIDxwcmUgd3Jh cD0iIj4JMy4JRm9yIE9TUEYsIGRvZXNuJ3Qgc29tZSBpbmZvcm1hdGlvbiBvbiB0aGUgdGlt ZXJzIChoZWxsbyBpbnRlcnZhbCwgZGVhZCBpbnRlcnZhbCwgcmV0cmFuc21pdCBpbnRlcnZh bCkgbmVlZCB0byBiZSBleGNoYW5nZWQsIHNvIHRoYXQgdGhlIGN1c3RvbWVyIGFuZCBTUCBj YW4gY29uZmlndXJlIHRoZWlyIGRldmljZXMgaW4gc3VjaCBhIHdheSB0aGF0IHRoZXkgd29u J3QgdGltZSBlYWNoIG90aGVyIG91dD8gIFBlcmhhcHMgdGhlIGludGVudCBpcyB0aGF0IHRo ZSBTUCBzcGVjaWZpZXMgdGhlc2UsIGFuZCBpdCdzIG5vdCBjb3ZlcmVkIGluIHRoZSBtb2Rl bCAoZ29pbmcgYmFjayB0byBteSBmaXJzdCBxdWVzdGlvbik/ICBJZiBzbywgaXQgd291bGQg YmUgdXNlZnVsIHRvIG1ha2UgdGhpcyBleHBsaWNpdC4NCg0KW0tPXSBBcyB5b3Ugd3JvdGUs IHRoYXQncyBuZWdvdGlhdGVkIG91dHNpZGUgb2YgdGhpcyBtb2RlbC48L3ByZT4NCiAgICA8 L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAgIDxmb250IGNvbG9yPSIjMDAwMDk5Ij5bREJd IE9rLjwvZm9udD48YnI+DQogICAgPGJyPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUi DQogICAgICBjaXRlPSJtaWQ6MDBkMzAxZDJlMDBiJGYwMjAwY2EwJGQwNjAyNWUwJEBrZGRp LmNvbSI+DQogICAgICA8cHJlIHdyYXA9IiI+CTQuCUZvciBPU1BGLCBhIG1ldHJpYyBjYW4g YmUgc3BlY2lmaWVkIC0gdGhlIG9ubHkgZGVzY3JpcHRpb24gaXMgIk1ldHJpYyBvZiB0aGUg UEUtQ0UgbGluayIuICBIb3cgaXMgdGhpcyBpbnRlbmRlZCB0byBiZSB1c2VkPyAgSG93IGRv ZXMgdGhpcyByZWxhdGUgdG8gdGhlICdhY2Nlc3MtcHJpb3JpdHknIGZvciB0aGUgc2l0ZS1u ZXR3b3JrLWFjY2Vzc2VzLCB3aGljaCBpcyBzdXBwb3NlZCB0byBiZSB1c2VkIHRvIGluZmx1 ZW5jZSBsb2FkLXNoYXJpbmcgYW5kIGFjdGl2ZS9zdGFuZGJ5Pw0KDQpbS09dIEFzIGRlc2Ny aWJlZCBhYm92ZSwgSSB0aGluayBob3cgdG8gYmVoYXZlIHRoZSBjb21iaW5hdGlvbiBvZiBh IHJvdXRpbmcgcHJvdG9jb2wgYW5kIGFuIGFjY2VzcyBwcmlvcml0eSBpcyB1cCB0byBhIFNQ LiBUaGUgcm91dGluZyBwcm90b2NvbCBtYXkgd29yayBvbiB0aGUgYWN0aXZlIGxpbmsgc3Bl Y2lmaWVkIGJ5IHRoZSBhY2Nlc3MgcHJpb3JpdHkuPC9wcmU+DQogICAgPC9ibG9ja3F1b3Rl Pg0KICAgIDxicj4NCiAgICA8Zm9udCBjb2xvcj0iIzAwMDA5OSI+W0RCXSBJIGRvbid0IHNl ZSBob3cgYSBjdXN0b21lciB3aWxsIGJlIGFibGUNCiAgICAgIHRvIHVzZSB0aGVzZSBwYXJh bWV0ZXJzIGNvcnJlY3RseS9hcHByb3ByaWF0ZWx5IGlmIHRoZQ0KICAgICAgY29ycmVzcG9u ZGluZyBiZWhhdmlvdXIgaXNuJ3QgY2xlYXJseSBkZXNjcmliZWQuwqAgV2hhdCBpcyBleHBl Y3RlZA0KICAgICAgdG8gaGFwcGVuIGlmIHRoZSBjdXN0b21lciBzZXRzIHRoZSBPU1BGIG1l dHJpYyB0byBhIHBhcnRpY3VsYXINCiAgICAgIHZhbHVlPzxicj4NCiAgICAgIChBbHNvLCBp ZiBpdCBpcyBhIHByb3ZpZGVyLW1hbmFnZWQgQ0UsIGlzIHRoaXMgcmVhbGx5IHRoZSBtZXRy aWMNCiAgICAgIG9mIHRoZSBQRS1DRSBsaW5rPyk8L2ZvbnQ+PGJyPg0KICAgIDxicj4NCiAg ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOjAwZDMwMWQyZTAw YiRmMDIwMGNhMCRkMDYwMjVlMCRAa2RkaS5jb20iPg0KICAgICAgPHByZSB3cmFwPSIiPgk1 LglGb3IgQkdQLCB0aGVyZSBpcyBhbiBBUyBudW1iZXIsIGJ1dCBpcyBpdCBzdXBwb3NlZCB0 byBiZSB0aGUgY3VzdG9tZXIncyBBUyBudW1iZXIgb3IgdGhlIFNQJ3MgQVMgbnVtYmVyPyAg VGhlIGRlc2NyaXB0aW9uIGp1c3Qgc2F5cyAiQVMgTnVtYmVyIiwgd2hpY2ggaXMgbm90IHZl cnkgaWxsdW1pbmF0aW5nLg0KCQkNCltLT10gVGhhdCdzIGN1c3RvbWVyJ3MgQVMgbnVtYmVy LiBJdCdzIG9idmlvdXMgdGhhdCBhIFNQIGhhcyBhbiBBUyBudW1iZXIgZm9yIHRoZWlyIEwz VlBOIHNlcnZpY2UuIEZvciBleGFtcGxlIG9mIEtEREksIDk5OTYgaXMgb3VyIElQVlBOIEFT IG51bWJlci48L3ByZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAgIDxmb250 IGNvbG9yPSIjMDAwMDk5Ij5bREJdIEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRvIGNs YXJpZnkNCiAgICAgIGl0LsKgIFFpbj88L2ZvbnQ+PGJyPg0KICAgIDxicj4NCiAgICA8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOjAwZDMwMWQyZTAwYiRmMDIw MGNhMCRkMDYwMjVlMCRAa2RkaS5jb20iPg0KICAgICAgPHByZSB3cmFwPSIiPgk2LglBbHNv IEkgdGhpbmsgdGhlcmUgaXMgYSBsb3QgbW9yZSB0aGF0IHdvdWxkIG5lZWQgdG8gYmUgYWdy ZWVkIG9uIGZvciBCR1A7IGZvciBpbnN0YW5jZSwgdGhlIHRpbWVycyAoc2ltaWxhciB0byB0 aGUgT1NQRiBjYXNlKSwgYXV0aGVudGljYXRpb24gKGUuZy4gTUQ1K3Bhc3N3b3JkKSwgd2hl dGhlciB0aGUgU1Agd2lsbCBhcHBseSAiQVMgb3ZlcnJpZGUiIGJlaGF2aW91ciwgZXRjLg0K DQpbS09dIFNhbWUgYXMgT1NQRi4gU29tZSBzcGVjaWZpYyBmdW5jdGlvbiBzaG91bGQgYmUg YXVnbWVudGVkIGlmIGEgU1Agd2FudHMgdG8gdXNlLCBhbHRob3VnaCB3ZSB3YW50IHRoZSBh dXRoZW50aWNhdGlvbi48L3ByZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAg IDxmb250IGNvbG9yPSIjMDAwMDk5Ij5bREJdIE9rLjwvZm9udD48YnI+DQogICAgPGJyPg0K ICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQogICAgICBjaXRlPSJtaWQ6MDBkMzAxZDJl MDBiJGYwMjAwY2EwJGQwNjAyNWUwJEBrZGRpLmNvbSI+DQogICAgICA8cHJlIHdyYXA9IiI+ CTcuCUZvciBkdWFsLXN0YWNrIEJHUCwgdGhlIHRleHQgc2F5cyBpdCBpcyB1cCB0byB0aGUg U1AgdG8gZGVjaWRlIHdoZXRoZXIgdG8gdXNlIG9uZSBzZXNzaW9uIG9yIHR3byBzZXNzaW9u cyAtIGJ1dCBjbGVhcmx5IHRoZSBjdXN0b21lciBuZWVkcyB0byBrbm93IHRoaXMgdG9vIHNv IHRoYXQgdGhleSBjYW4gY29uZmlndXJlIHRoZWlyIGRldmljZXMgYWNjb3JkaW5nbHkuICBJ cyB0aGF0IGludGVuZGVkIHRvIGJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBtb2RlbD8g IEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBjbGFyaWZ5IGl0Lg0KCQkNCltLT10gSSB0aGluayB0 aGlzIGlzIGFsc28gY29tbXVuaWNhdGVkIG91dHNpZGUgb2YgdGhlIG1vZGVsLjwvcHJlPg0K ICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+DQogICAgPGZvbnQgY29sb3I9IiMwMDAwOTki PltEQl0gT2suPC9mb250Pjxicj4NCiAgICA8YnI+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSINCiAgICAgIGNpdGU9Im1pZDowMGQzMDFkMmUwMGIkZjAyMDBjYTAkZDA2MDI1ZTAk QGtkZGkuY29tIj4NCiAgICAgIDxwcmUgd3JhcD0iIj4JOC4JSXQgYWxzbyBzYXlzIHRoYXQg dGhlIHNlc3Npb24gYWRkcmVzc2luZyBpcyBkZXJpdmVkIGZyb20gdGhlIGNvbm5lY3Rpb24g cGFyYW1ldGVycyAtIHRoaXMgaXMgYSBjb21tb24gY2FzZSwgYnV0IG5vdCB0aGUgb25seSB3 YXkgdG8gZG8gaXQuICBGb3IgZXhhbXBsZSwgaWYgdGhlcmUgYXJlIG11bHRpcGxlIHNpdGUt bmV0d29yay1hY2Nlc3NlcywgdGhlbiB0aGUgU1AgbWF5IGRlY2lkZSB0byB1c2UgYSBzaW5n bGUgQkdQIHNlc3Npb24gYmV0d2VlbiBsb29wYmFja3MsIHVzaW5nIEVCR1AtbXVsdGlob3As IHJhdGhlciB0aGFuIGEgc2VwYXJhdGUgQkdQIHNlc3Npb24gb24gZWFjaCBzaXRlLW5ldHdv cmstYWNjZXNzLiAgQ2FuIHRoZSBtb2RlbCBhY2NvbW9kYXRlIHRoaXMgY2FzZT8NCgkJDQpb S09dIFRoZSBjdXJyZW50IG1vZGVsIG9ubHkgc3VwcG9ydHMgdGhlIGxhdHRlciBjYXNlLiBB biBhcmd1bWVudGF0aW9uIGlzIHJlcXVpcmVkIGlmIGEgU1Agd2FudHMgdG8gdXNlIHRoZSBm b3JtZXIgb25lLjwvcHJlPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+DQogICAgPGZv bnQgY29sb3I9IiMwMDAwOTkiPltEQl0gT2suPC9mb250Pjxicj4NCiAgICA8YnI+DQogICAg PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCiAgICAgIGNpdGU9Im1pZDowMGQzMDFkMmUwMGIk ZjAyMDBjYTAkZDA2MDI1ZTAkQGtkZGkuY29tIj4NCiAgICAgIDxwcmUgd3JhcD0iIj4JOS4J Rm9yIHN0YXRpYyByb3V0aW5nLCBlYWNoIHByZWZpeCBoYXMgYSBtYW5kYXRvcnkgbmV4dGhv cDsgaG93ZXZlciwgZm9yIFAyUCBMMiB0ZWNobm9sb2dpZXMgKGUuZy4gUFBQLCBBVE0pLCB0 aGUgbmV4dGhvcCBtaWdodCBub3QgYmUgbmVlZGVkLCByaWdodD8NCg0KW0tPXSBGcm9tIGEg UEUncyBwZXJzcGVjdGl2ZSwgdGhlIG5leHQgaG9wIGZvciBhIExBTi9zdWJuZXQgYmVoaW5k IENFIHdpdGggUEUtQ0UgUDJQIGxpbmsgc2hvdWxkIGJlIHRoZSBDRSBlbmQgcG9pbnQgb2Yg dGhlIFAyUCBsaW5rLjwvcHJlPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+DQogICAg PGZvbnQgY29sb3I9IiMwMDAwOTkiPltEQl0gUmlnaHQsIGJ1dCBmb3IgYSBQMlAgTDIgdGVj aG5vbG9neSwgdGhlDQogICAgICBJUCBuZXh0aG9wIGRvZXNuJ3QgbmVlZCB0byBiZSBzcGVj aWZpZWQsIHJpZ2h0PzwvZm9udD48YnI+DQogICAgPGJyPg0KICAgIDxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiDQogICAgICBjaXRlPSJtaWQ6MDBkMzAxZDJlMDBiJGYwMjAwY2EwJGQwNjAy NWUwJEBrZGRpLmNvbSI+DQogICAgICA8cHJlIHdyYXA9IiI+MTQuCUxvdHMgb2YgcGFyYW1l dGVycyBjYW4gYmUgc3BlY2lmaWVkIGVpdGhlciBvbiB0aGUgc2l0ZSBvciBvbiB0aGUgc2l0 ZS1uZXR3b3JrLWFjY2Vzcy4gIEhvd2V2ZXIsIEJGRCBjYW4gb25seSBiZSBzcGVjaWZpZWQg b24gdGhlIHNpdGUtbmV0d29yay1hY2Nlc3MuICBJcyB0aGVyZSBhIHJlYXNvbiBmb3IgdGhp cz8gIEkgd291bGQgaGF2ZSB0aG91Z2h0IGlmIHlvdSB3YW50IEJGRCBvbiBvbmUgc2l0ZS1u ZXR3b3JrLWFjY2VzcywgeW91IHByb2JhYmx5IHdhbnQgaXQgb24gYWxsIG9mIHRoZW0sIHdp dGggdGhlIHNhbWUgcGFyYW1ldGVycywgc28gaGF2aW5nIHRoZSBwb3NzaWJpbGl0eSBvZiBz cGVjaWZ5aW5nIGl0IG9uY2UgdW5kZXIgdGhlIHNpdGUgd291bGQgc2VlbSB1c2VmdWwuDQoJ DQoNCltLT10gQXMgeW91IHdyb3RlLCB0aGUgY3VycmVudCBtb2RlbCBjYW4gY292ZXIgdGhl IGNhc2UsIGlmIGEgU1Agd2FudHMgdG8gZXh0ZW5kIHRvIGluaGVyaXQgc28sICBoZS9zaGUg Y2FuIGF1Z21lbnQuPC9wcmU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICA8 Zm9udCBjb2xvcj0iIzAwMDA5OSI+W0RCXSBBZ3JlZWQgLSBidXQgSSB3YXMgd29uZGVyaW5n IGlmIHRoZXJlIHdhcw0KICAgICAgYSByZWFzb24gaXQgd2FzIGRvbmUgdGhpcyB3YXkgb3Jp Z2luYWxseT/CoCBPciB3YXMgaXQganVzdCBhbg0KICAgICAgb3ZlcnNpZ2h0Pzxicj4NCiAg ICA8L2ZvbnQ+PGJyPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQogICAgICBjaXRl PSJtaWQ6MDBkMzAxZDJlMDBiJGYwMjAwY2EwJGQwNjAyNWUwJEBrZGRpLmNvbSI+DQogICAg ICA8cHJlIHdyYXA9IiI+MTUuCVNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSBJUHY0L0lQdjYg Y29ubmVjdGlvbiBmb3IgZWFjaCBzaXRlLW5ldHdvcmstYWNjZXNzOg0KDQoJMS4JV2hlbiBE SENQIGlzIHVzZWQsIHRoZSBwcm92aWRlciBhZGRyZXNzIGFuZCBtYXNrIGFyZW4ndCBzcGVj aWZpZWQgLSBidXQgZG9lc24ndCB0aGUgY3VzdG9tZXIgbmVlZCB0byBrbm93IHRoaXMsIHNv IGFzIHRvIGF2b2lkIGFsbG9jYXRpbmcgYWRkcmVzc2VzIHdpdGhpbiB0aGF0IHByZWZpeCB0 byB0aGVpciBpbnRlcm5hbCBkZXZpY2VzPyAgT3IgZG9lcyB0aGlzIGFnYWluIGZhbGwgaW50 byB0aGUgY2F0ZWdvcnkgb2YgaW5mb3JtYXRpb24gcGFzc2VkIGZyb20gdGhlIFNQIHRvIHRo ZSBjdXN0b21lciwgYW5kIGhlbmNlIG5vdCBpbiB0aGUgc2NvcGUgb2YgdGhlIG1vZGVsPw0K CQkNCgkyLglTaW1pbGFybHksIHdoZW4gREhDUCBpcyB1c2VkLCB0aGUgY3VzdG9tZXIgbWF5 IHN0aWxsIHdhbnQgc29tZSBzdGF0aWNhbGx5LWFzc2lnbmVkIGhvc3RzIG9uIHRoYXQgc3Vi bmV0IChlLmcuIGZvciBzZXJ2ZXJzIGV0YykuICBUaGVyZSBpcyBhIGxlYWYgZm9yIHNheWlu ZyBob3cgbWFueSBESENQIGFkZHJlc3NlcyBhcmUgYmVpbmcgcmVxdWVzdGVkLCBidXQgSSB0 aGluayB0aGUgY3VzdG9tZXIgd291bGQgYWxzbyBuZWVkIHRvIGtub3cgd2hpY2ggYWRkcmVz c2VzLCBzbyB0aGF0IHRoZXkgY2FuIGFzc2lnbiBvdGhlciBhZGRyZXNzZXMgb24gdGhhdCBz dWJuZXQgc3RhdGljYWxseSwgcmlnaHQ/DQoJCQ0KW0tPXSBBZ3JlZS4gRXZlbiBmb3IgdGhl IHByb3ZpZGVyLWRoY3AgY2FzZSwgYSBjdXN0b21lciBtdXN0IGF0IGxlYXN0IGJlIGFibGUg dG8gcmVxdWlyZSB0aGUgcHJvdmlkZXItYWRkcnNzLCBQRSBhZGRyZXNzL3N1Ym5ldC48L3By ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAgIDxmb250IGNvbG9yPSIjMDAw MDk5Ij5bREJdIEkgZ3Vlc3MgZ2l2ZW4geW91ciBvdGhlciBhbnN3ZXJzLCB0aGlzDQogICAg ICB3b3VsZCBiZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgbW9kZWw/PGJyPg0KICAgIDwv Zm9udD48YnI+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCiAgICAgIGNpdGU9Im1p ZDowMGQzMDFkMmUwMGIkZjAyMDBjYTAkZDA2MDI1ZTAkQGtkZGkuY29tIj4NCiAgICAgIDxw cmUgd3JhcD0iIj4JMy4JV2hlbiBESENQLVJlbGF5IGlzIHVzZWQsIGRvZXMgaXQgbWFrZSBz ZW5zZSB0byBoYXZlIGEgbXVsdGktVlBOIGNhc2U/ICBJJ20gbm90IHN1cmUgaG93IHRoZSBT UCB3b3VsZCBrbm93IHdoaWNoIFZQTiB0byBmb3J3YXJkIHRoZSBESENQIHJlcXVlc3RzIG92 ZXIgaW4gdGhpcyBjYXNlLg0KCQkNCltLT10gVGhlIGN1c3RvbWVyIG11c3Qgc3BlY2lmeSB0 aGUgREhDUCBzZXJ2ZXIgYWRkcmVzcywgYSBTUCBqdXN0IGZvcndhcmRzIGEgREhDUCByZXF1 ZXN0IHRoZXJlIGJhc2VkIG9uIHRoZSByb3V0aW5nIHRhYmxlIGV2ZW4gaW4gbXVsdGktVlBO IGNhc2UuPC9wcmU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICA8Zm9udCBj b2xvcj0iIzAwMDA5OSI+W0RCXSBPay48L2ZvbnQ+PGJyPg0KICAgIDxicj4NCiAgICA8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOjAwZDMwMWQyZTAwYiRmMDIw MGNhMCRkMDYwMjVlMCRAa2RkaS5jb20iPg0KICAgICAgPHByZSB3cmFwPSIiPgk0LglGb3Ig SVB2NiBjb25uZWN0aW9uLCBpcyB0aGVyZSBhIGNhc2Ugd2hlcmUgb25seSBsaW5rLWxvY2Fs IGFkZHJlc3NlcyBhcmUgdXNlZD8NCg0KW0tPXSBObywgYSBnbG9iYWwgb25lIGlzIGFsc28g c3VwcG9ydGVkLjwvcHJlPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8Zm9udCBjb2xvcj0i IzAwMDA5OSI+PGJyPg0KICAgICAgW0RCXSBJIG1lYW50LCBpZiB0aGUgY3VzdG9tZXIgd2Fu dGVkIHRvIHVzZSBvbmx5IExMIGFkZHJlc3NlcyBvbg0KICAgICAgdGhlIGxpbmssIGlzIHRo ZXJlIGEgd2F5IHRvIHNwZWNpZnkgdGhhdD88L2ZvbnQ+PGJyPg0KICAgIDxicj4NCiAgICA8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOjAwZDMwMWQyZTAwYiRm MDIwMGNhMCRkMDYwMjVlMCRAa2RkaS5jb20iPg0KICAgICAgPHByZSB3cmFwPSIiPjE2LglV bmRlciB0aGUgc2l0ZS1uZXR3b3JrLWFjY2VzcywgdGhlcmUgaXMgYSBzdmMtaW5wdXQtYmFu ZHdpZHRoIGFuZCBzdmMtb3V0cHV0LWJhbmR3aWR0aC4gIFNlY3Rpb24gNi4xMi4xIHNheXMg dGhhdCBpbnB1dC9vdXRwdXQgaXMgZnJvbSB0aGUgc2l0ZSdzIHBlcnNwZWN0aXZlLCBpLmUu ICJpbnB1dCBiYW5kd2lkdGgiIG1lYW5zIGRvd25sb2FkIGZyb20gdGhlIFNQIHRvd2FyZHMg dGhlIHNpdGUsIGFuZCAib3V0cHV0IGJhbmR3aWR0aCIgbWVhbnMgdXBsb2FkIGZyb20gdGhl IHNpdGUgdG93YXJkcyB0aGUgU1AuICBIb3dldmVyLCB0aGUgZGVzY3JpcHRpb25zIG9mIHRo ZSBsZWF2ZXMgd2l0aGluIHRoZSBtb2R1bGUgc2F5IHRoZSBvcHBvc2l0ZTogc3ZjLWlucHV0 LWJhbmR3aWR0aCBpcyAiRnJvbSB0aGUgUEUncyBwZXJzcGVjdGl2ZSwgdGhlIHNlcnZpY2Ug aW5wdXQgYmFuZHdpZHRoIG9mIHRoZSBjb25uZWN0aW9uLiIgYW5kIGxpa2V3aXNlIGZvciBv dXRwdXQuICBUbyBteSBtaW5kLCBleHByZXNzaW5nIHRoaXMgZnJvbSB0aGUgU1AncyBwZXJz cGVjdGl2ZSBtYWtlcyBtb3JlIHNlbnNlIChpLmUuLCBpdCBpcyBpbnB1dCB0byBvciBvdXRw dXQgZnJvbSB0aGUgVlBOIHNlcnZpY2UpIC0gYnV0IGVpdGhlciB3YXksIHRoZSBkb2N1bWVu dCBzaG91bGQgYmUgY29uc2lzdGVudCBhbmQgbm90IGNvbnRyYWRpY3QgaXRzZWxmLiAgTm90 ZSB0aGF0IHRoZXNlIGxlYXZlcyBhcmUgYWxzbyByZWZlcmVkIHRvIGluIHNlY3Rpb24gNi4x Mi4yLjIgZm9yIHRoZSBRb1MgcHJvZmlsZSAtIHRoYXQgdGV4dCBtaWdodCBhbHNvIGJlIGFm ZmVjdGVkIHdoZW4gcmVzb2x2aW5nIHRoZSBjb25mbGljdC4NCg0KW0tPXSBBZ3JlZS48L3By ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAgIDxmb250IGNvbG9yPSIjMDAw MDk5Ij5bREJdIFFpbiwgd2lsbCB5b3UgZml4IHRoaXM/PC9mb250Pjxicj4NCiAgICA8YnI+ DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCiAgICAgIGNpdGU9Im1pZDowMGQzMDFk MmUwMGIkZjAyMDBjYTAkZDA2MDI1ZTAkQGtkZGkuY29tIj4NCiAgICAgIDxwcmUgd3JhcD0i Ij4xNy4JVGhlIGFjY2Vzcy1wcmlvcml0eSBsZWFmIGlzIHN1cHBvc2VkIHRvIGJlIHVzZWQg dG8gZGVmaW5lIGEgcHJlZmVyZW5jZSBmb3IgbG9hZC1iYWxhbmNpbmcgb3IgYWN0aXZlL3N0 YW5kYnkgd2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgc2l0ZS1uZXR3b3JrLWFjY2Vzc2VzLiAg SG93ZXZlciwgaXQgd2Fzbid0IGNsZWFyIHRvIG1lIHdoZXRoZXIgdGhpcyB3YXMgaW50ZW5k ZWQgdG8gYXBwbHkgdG8gaW5ncmVzcyB0cmFmZmljLCBlZ3Jlc3MgdHJhZmZpYywgb3IgYm90 aDsgb3IgaG93IGl0IHJlbGF0ZXMgdG8gdGhlIHJvdXRpbmcgcHJvdG9jb2wgbWV0cmljcy9j b3N0cy4gIFdoZW4gdGhlIGN1c3RvbWVyIHNlbmRzIHRyYWZmaWMgdG93YXJkcyB0aGUgU1As IHRoZXkgY2FuIGNob3NlIHdoaWNoZXZlciBzaXRlLW5ldHdvcmstYWNjZXNzIHRoZXkgbGlr ZSwgYW5kIHRoZSBTUCBzaG91bGQgZGVsaXZlciB0aGUgdHJhZmZpYywgc28gaXQgc2VlbXMg dGhhdCBub3RoaW5nIG5lZWRzIHRvIGJlIHNwZWNpZmllZCBpbiB0aGF0IGNhc2U7IGlmIHNv LCB0aGUgYWNjZXNzLXByaW9yaXR5IHdvdWxkIG9ubHkgYXBwbHkgdG8gdHJhZmZpYyBmbG93 aW5nIGZyb20gdGhlIFNQIHRvIHRoZSBjdXN0b21lci4gIEhvd2V2ZXIsIGFzc3VtaW5nIGEg ZHluYW1pYyByb3V0aW5nIHByb3RvY29sIGlzIHVzZWQsIHRoZSBjdXN0b21lciBvdWdodCB0 byBiZSBhYmxlIHRvIGluZmx1ZW5jZSB0aGF0IGJ5IGFkdmVydGlzaW5nIGRpZmZlcmVudCBt ZXRyaWNzIG9uIHRoZSBkaWZmZXJlbnQgc2l0ZS1uZXR3b3JrLWFjY2Vzc2VzIChwcm92aWRl ZCB0aGUgU1AgaG9ub3VycyB0aGVzZSkuICBUaGUgb25seSBtb3JlIGNvbXBsZXggY2FzZSBJ IGNvdWxkIHRoaW5rIG9mIGlzIHdoZXJlIHRoZXJlJ3MgYSBkZXNpcmUgdG8gZW5zdXJlIHRo YXQgdHJhZmZpYyBhbHdheXMgZmxvd3MgYmlkaXJlY3Rpb25hbGx5IG9uIHRoZSBzYW1lIGxp bmsgLSBidXQgdGhlbiwgSQ0KY291bGRuJ3QgZmlndXJlIG91dCBob3cgdGhlIGFjY2Vzcy1w cmlvcml0eSBjb3VsZCBoZWxwIHdpdGggdGhhdC4gIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/ DQoNCltLT10gQXMgYWJvdmUgZGVzY3JpYmVkLCBJIHRoaW5rIEhvdyB0aGlzIHdvcmtzIGlz IHVwIHRvIGEgU1AuPC9wcmU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICA8 Zm9udCBjb2xvcj0iIzAwMDA5OSI+W0RCXSBPayAtIGJ1dCBpdCBkb2Vzbid0IHNlZW0gdmVy eSB1c2VmdWwgaWYNCiAgICAgIHRoZSBjdXN0b21lciBkb2Vzbid0IGtub3cgaG93IHRoZSBT UCB3aWxsIHVzZSBpdDsgaG93IHdpbGwgdGhlDQogICAgICBjdXN0b21lciBrbm93IHdoYXQg dG8gcmVxdWVzdD88L2ZvbnQ+PGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgwqDCoMKg IERhdmlkPGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSINCiAgICAgIGNpdGU9Im1pZDowMGQzMDFkMmUwMGIkZjAyMDBjYTAkZDA2MDI1ZTAk QGtkZGkuY29tIj4NCiAgICAgIDxwcmUgd3JhcD0iIj4NCg0KDQpPbiAwOS8wNS8yMDE3IDE0 OjU3LCBRaW4gV3Ugd3JvdGU6DQoNCg0KCURlYXIgTDNTTSBsaXN0LA0KCQ0KCUFzIHlvdSBz YXcsIEphbiBkaWQgYSB2ZXJ5IGdvb2QgcmV2aWV3IG9mIHRoZSBMM1NNIFlBTkcgbW9kZWws IGFuZCB0aGVyZSBoYXMNCgliZWVuIGEgbGl0dGxlIGRpc2N1c3Npb24gb24gdGhpcyBsaXN0 Lg0KCQ0KCUkgYW0gcHJlcGFyaW5nIGEgYmlzIGRyYWZ0IHRvIGluY2x1ZGUgYWxsIG9mIHRo ZSBjb21tZW50cy4gVGhlIHBsYW4gaXM6DQoJLSBJIHNob3cgdGhlIGRyYWZ0IHRvIEphbiBh bmQgdGhlIGF1dGhvcnMgb2YgdGhlIFJGQw0KCS0gSSBwb3N0IHRoZSBkcmFmdA0KCS0gV2Ug cmV2aWV3IGl0IG9uIHRoaXMgbGlzdA0KCS0gV2UgYXNrIEJlbm9pdCB0byBBRCBzcG9uc29y IGl0DQoJDQoJSSBob3BlIHRvIGhhdmUgdGhlIHJldmlzaW9uIHJlYWR5IHZlcnkgc29vbi4N CgkNCglSZWdhcmRzLA0KCVFpbg0KCQ0KCQ0KCVNlbnQgZnJvbSBIVUFXRUkgQW55T2ZmaWNl DQoNCgkgDQoJDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCglMM3NtIG1haWxpbmcgbGlzdA0KCTxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJi cmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpMM3NtQGlldGYub3JnIj5MM3NtQGlldGYub3JnPC9h Pg0KCTxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sM3NtPC9hPg0KDQoNCjwvcHJlPg0KICAgIDwvYmxvY2txdW90 ZT4NCiAgICA8YnI+DQogICAgPHByZSBjbGFzcz0ibW96LXNpZ25hdHVyZSIgY29scz0iNzIi Pi0tIA0KRGF2aWQgQmFsbA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJl Zj0ibWFpbHRvOmRhdmliYWxsQGNpc2NvLmNvbSI+Jmx0O2RhdmliYWxsQGNpc2NvLmNvbSZn dDs8L2E+PC9wcmU+DQogIDwvYm9keT4NCjwvaHRtbD4NCg== --------------F4461172FD60014C70DBDC7F-- From nobody Wed Jun 14 02:19:55 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B74128B37 for ; Wed, 14 Jun 2017 02:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOH9c7PTokT2 for ; Wed, 14 Jun 2017 02:19:49 -0700 (PDT) Received: from post-send.kddi.com (athena4.kddi.com [27.90.165.197]) by ietfa.amsl.com (Postfix) with ESMTP id 07AA8126CF9 for ; Wed, 14 Jun 2017 02:19:49 -0700 (PDT) Received: from LTMC2122.kddi.com (LTMC2122.kddi.com [10.206.0.63]) by post-send.kddi.com (KDDI Mail) with ESMTP id 07878120041; Wed, 14 Jun 2017 18:19:48 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2122.kddi.com with ESMTP; Wed, 14 Jun 2017 18:19:47 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id E20F54C005A; Wed, 14 Jun 2017 18:19:47 +0900 (JST) Received: from LTMC2151.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id D6DE64C0058; Wed, 14 Jun 2017 18:19:47 +0900 (JST) Received: from LTMC2151.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id v5E9JlMt009068; Wed, 14 Jun 2017 18:19:47 +0900 Received: from LTMC2151.kddi.com.mid_21716416 (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id v5E99hjT048812; Wed, 14 Jun 2017 18:09:43 +0900 X-SA-MID: 21716416 Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Wed, 14 Jun 2017 18:09:43 +0900 From: "Ogaki, Kenichi" To: "'David Ball'" , "'Qin Wu'" , References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> In-Reply-To: <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> Date: Wed, 14 Jun 2017 18:09:43 +0900 Message-ID: <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ja Thread-Index: AQI8KJ/JrK2KyxsjaGJAhXNMm3Sl2gG6ddmrAczEpsMBsDkrZKEns34g X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:19:54 -0000 Hi David, Thanks for you comments. See more comments inline, please. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball Sent: Monday, June 12, 2017 11:39 PM To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org Subject: Re: [L3sm] Next Step of RFC8049 Thanks Kenichi, please see further thoughs inline: On 08/06/2017 05:01, Ogaki, Kenichi wrote: 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:l3sm-bounces@ietf.org] On Behalf Of David Ball Sent: Saturday, June 03, 2017 12:08 AM To: Qin Wu; l3sm@ietf.org 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. [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. 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. [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. 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. [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. 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. [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. 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. [DB] So is there a reason it was not done that way? [KO] The requirement that a VPN want to connect multiple clouds still exists. The latter case cannot cover this. 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. [DB] Qin, will you be fixing this in the bis version? 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. [DB] Ok. 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. [DB] Anyone else? It doesn't seem useful to have a leaf in the model if we don't know what it means... 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. [DB]: Ok, yes I can see how implementing that might not be straightforward. 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. [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. 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. [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. 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. [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. 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? [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] 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. 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. [DB] Ok. 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. [DB] Ok. 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. [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. 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. [DB] I think it would be useful to clarify it. Qin? 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. [DB] Ok. 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. [DB] Ok. 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. [DB] Ok. 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. [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. 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. [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. 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. [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. 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. [DB] Ok. 4. For IPv6 connection, is there a case where only link-local addresses are used? [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? [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. 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. [DB] Qin, will you fix this? 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. [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 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 L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm -- David Ball From nobody Tue Jun 20 10:33:06 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147761315A2 for ; Tue, 20 Jun 2017 10:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq93moGctRd6 for ; Tue, 20 Jun 2017 10:33:00 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D40F13155E for ; Tue, 20 Jun 2017 10:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24377; q=dns/txt; s=iport; t=1497979980; x=1499189580; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=C2OrP1gOP36W9jFH7pLDcavRPpJOpPi4Dp4chh9zMcE=; b=lDOtHGUGw1y4W0dNLfd3VbcqWZaC4fDcFRlxZWXXY1RbnLnz/WKY/unV h4ahtgSTd3ULIMUeL7LcbQt34nDmqiz31fNs0PMErKqhOPGjinKBmSI7z ZY5QZoRMMZ+mK2ZFey3EwF6BQ24m9WEt/BC7h/rszGL8VIYAa5VFEmFaS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AAD9W0lZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqBDYNrihlzkQyVeIIOAyELhXgCgyUYAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECAQEBGAkVNhAHBAsRBAEBAQICFA8DAgInHwkIBgEMBgIBARUCigkIEKpFE?= =?us-ascii?q?YEjgiaLWAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFYYFfASuBbYEMgTyCcxc?= =?us-ascii?q?DCjwGIoJEgmEFiUiGeYFdjEOIOYI3iHKCCINEggSDS4ZzjEaIRx84gQowIQgbF?= =?us-ascii?q?UmFDQEEBxCBZQI/Nocbgj4BAQE?= X-IronPort-AV: E=Sophos;i="5.39,364,1493683200"; d="scan'208";a="695286861" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2017 17:32:51 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v5KHWook018776; Tue, 20 Jun 2017 17:32:51 GMT To: "Ogaki, Kenichi" , "'Qin Wu'" , l3sm@ietf.org References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> From: David Ball Message-ID: <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> Date: Tue, 20 Jun 2017 18:32:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 17:33:05 -0000 Thanks Kenichi - more comments inline. It would be great to hear some other opinions too. On 14/06/2017 10:09, Ogaki, Kenichi wrote: > Hi David, > > Thanks for you comments. > See more comments inline, please. > > Thanks, > Kenichi > > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Monday, June 12, 2017 11:39 PM > To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org > Subject: Re: [L3sm] Next Step of RFC8049 > > Thanks Kenichi, please see further thoughs inline: > > > > On 08/06/2017 05:01, Ogaki, Kenichi wrote: > > > 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:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Saturday, June 03, 2017 12:08 AM > To: Qin Wu; l3sm@ietf.org > 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. > > > [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. > > > > 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. > > > [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. [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? > 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. > > > [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. [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? > 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. > > > [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] 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? > 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. > > > [DB] So is there a reason it was not done that way? > > [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? > 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. > > [DB] Qin, will you be fixing this in the bis version? > > > > 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. > > > [DB] Ok. > > > > 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. > > > [DB] Anyone else? It doesn't seem useful to have a leaf in the model if we don't know what it means... > > > > 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. > > > [DB]: Ok, yes I can see how implementing that might not be straightforward. > > > > 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. > > > [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. [DB2] Right - so shouldn't the model support it? > 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. > > > [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. [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. > 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. > > > [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. [DB2] My question was specifically about when the end-to-end leaf is set to true. > 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? > > > [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] 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". > 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. > > > [DB] Ok. > > > > 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. > > > [DB] Ok. > > > > 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. > > > [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. [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. > 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. > > > [DB] I think it would be useful to clarify it. Qin? > > > > 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. > > > [DB] Ok. > > > > 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. > > > [DB] Ok. > > > > 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. > > > [DB] Ok. > > > > 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. > > > [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. [DB2] Ok. > 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. > > > [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. [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? > 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. > > > [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. [DB2] Ok. Qin, should we add this? > 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. > > > [DB] Ok. > > > > 4. For IPv6 connection, is there a case where only link-local addresses are used? > > [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? > > [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 > 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. > > > [DB] Qin, will you fix this? > > > > 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. > > > [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 > > > > > > > > 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 > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm > > > > -- David Ball From nobody Wed Jun 21 02:56:28 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B2C131CF8 for ; Wed, 21 Jun 2017 02:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI9Po8hZer47 for ; Wed, 21 Jun 2017 02:56:23 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3554131CE3 for ; Wed, 21 Jun 2017 02:56:22 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 404511C00D6; Wed, 21 Jun 2017 11:56:21 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 0CB19800CA; Wed, 21 Jun 2017 11:56:21 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0352.000; Wed, 21 Jun 2017 11:56:20 +0200 From: To: David Ball , "Ogaki, Kenichi" , 'Qin Wu' , "l3sm@ietf.org" Thread-Topic: [L3sm] Next Step of RFC8049 Thread-Index: AdLIzCXxBcQvJgePTDyhRzLdDi5cBQS1Ro4AARZ7CAAA32+/gABZEcKAAT9R1QAAJGJoYA== Date: Wed, 21 Jun 2017 09:56:20 +0000 Message-ID: <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> In-Reply-To: <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 09:56:27 -0000 Hi, Please find some comments inline (marked with [SLI]) -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball Sent: Tuesday, June 20, 2017 19:33 To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org Subject: Re: [L3sm] Next Step of RFC8049 Thanks Kenichi - more comments inline. It would be great to hear some othe= r opinions too. On 14/06/2017 10:09, Ogaki, Kenichi wrote: > Hi David, > > Thanks for you comments. > See more comments inline, please. > > Thanks, > Kenichi > > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Monday, June 12, 2017 11:39 PM > To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org > Subject: Re: [L3sm] Next Step of RFC8049 > > Thanks Kenichi, please see further thoughs inline: > > > > On 08/06/2017 05:01, Ogaki, Kenichi wrote: > > > Hi David, >=20=09 > As an author and operator, see comments inline, please. > Stephane, luis, could you correct me if I misunderstand? >=20=09 > Thanks, > Kenichi >=20=09 > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Saturday, June 03, 2017 12:08 AM > To: Qin Wu; l3sm@ietf.org > Subject: Re: [L3sm] Next Step of RFC8049 >=20=09 > Hi Qin, >=20=09 >=20=09 > As you are working on a bis version, I have a few questions on RFC8049 t= hat might lead to discussion on the list, and perhaps some further changes. >=20=09 >=20=09 > 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, clea= rly for the customer to be able to use the service, there is also informati= on 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 f= ine, but it would be helpful to make this clearer (perhaps in section 5?) >=20=09 > [KO] That's right. > > > [DB]: Ok, thanks. Qin, if you are developing a bis version, it would def= initely help to make this clearer near the start of the doc. > > > > 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 descri= bes a case where a single "site" could be in multiple locations that are in= terconnected independently of the VPN service - the example given is multip= le offices in the same city. Does this extend more generally? E.g., if tw= o 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" alway= s completely disconnected (topologically) from other sites (other than via = the VPN service)? >=20=09 > [KO] This case of the backdoor is a corner case and a service model shou= ld not define such corner cases. > > > [DB] Ok - but what about my more general question? Is a single site alwa= ys assumed to be topologically disconnected from other sites? > > [KO] I don't think so. If a customer connects two sites with a backdoor a= nd appropriately advertises both sites' routes to both connected PEs by usi= ng a dynamic routing protocol, both sites should still be reachable when th= e break of one of PE-CE links occurs. [DB2] Ok - so in general, if the Subscriber has a number of access connections=20 (i.e. site-network-accesses) connecting various parts of their network=20 (wherever they are located) to the SP, it is up to them to determine how=20 to group them into sites? [SLI] The site is a notion that is defined by the customer. It could be a s= ingle 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 area= s of a city). This flexibility is required for multihoming, as a lot of customers host th= e two CPEs in two different physical locations. > 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 str= ong communication isolation". Does "this case" mean the sub-VPN case or th= e multiple sites case? Either way, the customer could share physical compo= nents and maintain strong isolation, right? >=20=09 > [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 gu= ess I don't understand the purpose of having sub-VPN as an option - but goo= d to know there is nothing extra I'm missing here. > > [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=20 should be modelled as a sub-VPN instead of modelling at separate sites?=20= =20 The same scenario can be expressed either way, right? [SLI] We had this debate earlier when modeling the subVPN (using multiple s= ites was one of the possibility but not retained). The subVPNs has the particularity of sharing a common bearer and a common C= PE (it's a VRF lite CPE in term of configuration). > 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 wo= uld have thought the customer name would be known out-of-band, e.g. from th= e AAA for the request? It would be bad if one customer could request thing= s for another customer by filling in a different customer name in the model! >=20=09=09 > [KO] A customer can only access the model instance of that customer. Ple= ase see section 10. > > > [DB] Yes exactly - if a customer can only access their own instance of th= e 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 mode= l. It seems like the customer-name leaf is unnecessary? > > [KO] As common usecases, a VPN service is provided not only by Tier 1 pro= viders, but also by Tier 2 providers or IT divisions of enterprises in orde= r 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 managemen= t purposes. [DB2] I didn't really follow this, sorry. The module contains the information=20 that needs to be sent from the customer to the SP, right? If the=20 customer using the model (i.e. the Tier2 in your above example) needs to=20 track which of their own customers the service is for, that's something=20 that's internal to them, isn't it? > 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 t= han having a separate VPN service to connect to each cloud service? If the= re was a separate VPN service for each cloud service, then only the right s= ites would be attached to the VPN for each cloud, and it would not be neces= sary to have a separate list of authorized sites, right? >=20=09=09 > [KO] That's right. > > > [DB] So is there a reason it was not done that way? > > [KO] The requirement that a VPN want to connect multiple clouds still exi= sts. The latter case cannot cover this. [DB2] Can you give an example that can be modelled with multiple clouds in a=20 single VPN that could not be modelled as multiple VPNs? [SLI] Using multiple VPNs has a major impact on the service design (not tal= king 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 ca= n 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/u= nauthorized sites. Now in term of implementation, you can do what you want, you can create add= itional VPNs, you can use ACLs or whatever... but from a service perspectiv= e, the customer has a single VPN and a cloud access with limited access. > 6. On that subject, the yang module has /l3vpn-svc/vpn-services/vpn-serv= ice/cloud-accesses/cloud-access/list-flavor, which is a choice of permit-an= y, permit-any-except and deny-any-except. It also has /l3vpn-svc/vpn-servi= ces/vpn-service/cloud-accesses/cloud-access/authorized-sites and /l3vpn-svc= /vpn-services/vpn-service/cloud-accesses/cloud-access/denied-sites, which s= eem 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 s= ection 6.2.2 only mentions the first one (list-flavor/...). >=20=09 >=20=09 > [KO] I think you are right. deny-any-except looks same as authorized-sit= es, and permit-any-except does denied-sites. > > [DB] Qin, will you be fixing this in the bis version? [SLI] oh yes, authorized-sites/denied-sites was an old style of modeling th= at we normally removed (it seems that we missed to remove it). > > > 7. Sticking with cloud access, there is an option for enabling NAT44. H= owever, only a single address can be specified. For some big enterprise cu= stomers, when NAT is used, more than one public-facing address is needed (t= ypically from the same IP prefix) - is there a way to accommodate that case? >=20=09 > [KO] The current model can cover the case. SP just has to pick a range o= f addresses, but some augmentations, how many addresses are required, is de= sired. > > > [DB] Ok. > > > > 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 use= d. At least for IPv4, packets larger than the MTU can be fragmented (altho= ugh 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 c= an be certain that packets shorter than that will be delivered. Of course,= the customer might use techniques like path MTU discovery to determine tha= t they can use a larger MTU for particular paths. I think it would be usef= ul to have some discussion of this topic in the RFC. >=20=09 > [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... > > [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 mak= e it working. > > 9. There is a per-site limit on the number of IPv4/IPv6 routes ("maximu= m-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 b= e useful to have a per-site, per-VPN limit, e.g. in the case where one of t= he VPNs is an extranet, to limit the number of prefixes that can be adverti= sed into the extranet at that site? >=20=09=09 > [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 straightforwar= d. > > > > 10. There is a qos-classification-policy (either per-site or per-site-ne= twork-access), which describes how to map packets to the right class of ser= vice. In a single-VPN case, this is fine, but I am not sure how to interpr= et it when the site is attached to multiple VPNs. The different VPNs might= have different classes of service, so doesn't the classification policy ne= ed to be per-site per-VPN, not just per-site? >=20=09 > [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-VP= N 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/out= put of PE, not differentiate it per VPN. But, other SPs may want this. [DB2] Right - so shouldn't the model support it? [SLI] I'm not sure this is necessary, in the multiVPN case, the site is "sh= ared", so the customer expects flows to go to sites that are located in dif= ferent VPNs. The customer can use the dst-prefix or the target-site in orde= r to set a particular class for a particular flow whatever the VPN. > 11. The related qos-profile has constraints on latency and jitter; howev= er, these apply to all packets in a flow. So, for example, if there were s= ites in London, Paris and San Francisco, the same latency constraint would = apply to packets from London to Paris and packets from London to San Franci= sco, which doesn't seem very useful. Similarly, in a multi-VPN case, the s= ame constraints would apply regardless of which VPN the packet maps to. Th= is 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? >=20=09=09 > [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] 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=20 specify the latency or jitter from London to Paris, it is just a single=20 value for the VPN as a whole. [SLI] I think you can, you just need more classes.=20 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 guaran= teed BW... > 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 shoul= d 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? >=20=09=09 > [KO] Same comment as above. As I know, a SP controls the bandwidth at in= put/output of PE. > > > [DB] Agreed - but again, the question is about the meaning of the attribu= te rather than where the SP implements it. In a VPN with 10 sites, what do= es 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. I= f a SP wants an end-to-end qos, he/she must negotiate some constraints or c= onditions with her/his customer outside of this model. [DB2] My question was specifically about when the end-to-end leaf is set=20 to true. [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 involve= d. > 13. Lots of questions about the routing-protocols: >=20=09 > 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 us= e, right? So, what is the difference between specifying routing protocol "= direct", and leaving the routing protcol list empty? >=20=09 >=20=09 > [KO] The list routing-protocol has the entity with "type" as the key. Th= en empty routing protocol is not allowed. > > > [DB] I meant an empty list, not an empty element in the list. There is n= o "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 li= st is empty. [DB2] Right - so if the "direct" case can be represented by an empty=20 list, then there is no need to explicitly specify "direct". [SLI] Some SPs prevents to advertise the interco subnet except if the custo= mer really requires it. > 2. The purpose of VRRP is to be opaque to the customer - so it's not cl= ear why the customer would explicitly request this? Is the intent to captu= re 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 ac= cess constraint for "l2-diverse"? >=20=09=09=09 > [KO] From an operator's perspective, VRRP has common consensus for L3VPN= customers rather than what l2-diverse means. > > > [DB] Ok. > > > > 3. For OSPF, doesn't some information on the timers (hello interval, de= ad interval, retransmit interval) need to be exchanged, so that the custome= r and SP can configure their devices in such a way that they won't time eac= h other out? Perhaps the intent is that the SP specifies these, and it's n= ot covered in the model (going back to my first question)? If so, it would= be useful to make this explicit. >=20=09 > [KO] As you wrote, that's negotiated outside of this model. > > > [DB] Ok. > > > > 4. For OSPF, a metric can be specified - the only description is "Metri= c of the PE-CE link". How is this intended to be used? How does this rela= te to the 'access-priority' for the site-network-accesses, which is suppose= d to be used to influence load-sharing and active/standby? >=20=09 > [KO] As described above, I think how to behave the combination of a rout= ing protocol and an access priority is up to a SP. The routing protocol may= work on the active link specified by the access priority. > > > [DB] I don't see how a customer will be able to use these parameters corr= ectly/appropriately if the corresponding behaviour isn't clearly described.= What is expected to happen if the customer sets the OSPF metric to a part= icular value? > (Also, if it is a provider-managed CE, is this really the metric of the P= E-CE link?) > > [KO] As I wrote, a SP must inform how this mechanism works to his/her cus= tomer outside of this model. It depends on each SP's implementation. [DB2] Ok; in my opinion, having things in the model without any=20 information about how they should be used is not useful, but so be it. > 5. For BGP, there is an AS number, but is it supposed to be the custome= r's AS number or the SP's AS number? The description just says "AS Number"= , which is not very illuminating. >=20=09=09=09 > [KO] That's customer's AS number. It's obvious that a SP has an AS numbe= r 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? > > > > 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. >=20=09 > [KO] Same as OSPF. Some specific function should be augmented if a SP wa= nts to use, although we want the authentication. > > > [DB] Ok. > > > > 7. For dual-stack BGP, the text says it is up to the SP to decide wheth= er to use one session or two sessions - but clearly the customer needs to k= now 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 clar= ify it. >=20=09=09=09 > [KO] I think this is also communicated outside of the model. > > > [DB] Ok. > > > > 8. It also says that the session addressing is derived from the connect= ion 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 deci= de to use a single BGP session between loopbacks, using EBGP-multihop, rath= er than a separate BGP session on each site-network-access. Can the model = accomodate this case? >=20=09=09=09 > [KO] The current model only supports the latter case. An argumentation i= s required if a SP wants to use the former one. > > > [DB] Ok. > > > > 9. For static routing, each prefix has a mandatory nexthop; however, fo= r P2P L2 technologies (e.g. PPP, ATM), the nexthop might not be needed, rig= ht? >=20=09 > [KO] From a PE's perspective, the next hop for a LAN/subnet behind CE wi= th 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 b= e 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. [DB2] Ok. > 14. Lots of parameters can be specified either on the site or on the sit= e-network-access. However, BFD can only be specified on the site-network-a= ccess. Is there a reason for this? I would have thought if you want BFD o= n one site-network-access, you probably want it on all of them, with the sa= me parameters, so having the possibility of specifying it once under the si= te would seem useful. >=20=09=09 >=20=09 > [KO] As you wrote, the current model can cover the case, if a SP wants t= o 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] I think, if a solution covers two requirements, each solution for ea= ch requirement is not always necessary. [DB2] Agreed - my question is why, in this particular case, only the=20 per-access solution was included whereas for other attributes, both=20 mechanisms were included. What was the specific rationale for not=20 adding BFD as a per-site attribute? > 15. Some questions about the IPv4/IPv6 connection for each site-network-= access: >=20=09 > 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 addre= sses 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 h= ence not in the scope of the model? >=20=09=09=09 > 2. Similarly, when DHCP is used, the customer may still want some stati= cally-assigned hosts on that subnet (e.g. for servers etc). There is a lea= f for saying how many DHCP addresses are being requested, but I think the c= ustomer would also need to know which addresses, so that they can assign ot= her addresses on that subnet statically, right? >=20=09=09=09 > [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] No, I think the model should definitely specify this. [DB2] Ok. Qin, should we add this? > 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 request= s over in this case. >=20=09=09=09 > [KO] The customer must specify the DHCP server address, a SP just forwar= ds a DHCP request there based on the routing table even in multi-VPN case. > > > [DB] Ok. > > > > 4. For IPv6 connection, is there a case where only link-local addresses= are used? >=20=09 > [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? > > [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=20 moment. Qin, something else to add? David > 16. Under the site-network-access, there is a svc-input-bandwidth and sv= c-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 t= he 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 band= width 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 ou= tput from the VPN service) - but either way, the document should be consist= ent 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. >=20=09 > [KO] Agree. > > > [DB] Qin, will you fix this? > > > > 17. The access-priority leaf is supposed to be used to define a preferen= ce for load-balancing or active/standby when there are multiple site-networ= k-accesses. However, it wasn't clear to me whether this was intended to ap= ply to ingress traffic, egress traffic, or both; or how it relates to the r= outing protocol metrics/costs. When the customer sends traffic towards the= SP, they can chose whichever site-network-access they like, and the SP sho= uld 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 f= rom the SP to the customer. However, assuming a dynamic routing protocol i= s used, the customer ought to be able to influence that by advertising diff= erent metrics on the different site-network-accesses (provided the SP honou= rs 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? >=20=09 > [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 ho= w 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 > > > > >=20=09 >=20=09 >=20=09 > On 09/05/2017 14:57, Qin Wu wrote: >=20=09 >=20=09 > Dear L3SM list, >=20=09=09 > As you saw, Jan did a very good review of the L3SM YANG model, and ther= e has > been a little discussion on this list. >=20=09=09 > 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 >=20=09=09 > I hope to have the revision ready very soon. >=20=09=09 > Regards, > Qin >=20=09=09 >=20=09=09 > Sent from HUAWEI AnyOffice >=20=09 >=20=09=09 >=20=09=09 > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm >=20=09 >=20=09 > > --=20 David Ball _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 nobody Wed Jun 21 22:21:14 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DD9126DED for ; Wed, 21 Jun 2017 22:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXzfOCc3xTCT for ; Wed, 21 Jun 2017 22:21:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA11A1200CF for ; Wed, 21 Jun 2017 22:21:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPP38275; Thu, 22 Jun 2017 05:21:04 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 22 Jun 2017 06:21:03 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 22 Jun 2017 13:20:59 +0800 From: Qin Wu To: David Ball , "l3sm@ietf.org" Thread-Topic: [L3sm] Next Step of RFC8049 Thread-Index: AdLIzCXxBcQvJgePTDyhRzLdDi5cBQSos+gAA+ntw6A= Date: Thu, 22 Jun 2017 05:20:59 +0000 Message-ID: References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> In-Reply-To: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A976E04nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.594B53C1.001F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 09cd5f5c66d70c8f50c2790042f914ea Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 05:21:13 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9A976E04nkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmtzIERhdmlkIGZvciB0YWtpbmcgYSBzdGFiIGludG8gUkZDODA0OSBhbmQgcHJvdmlkZSBh IGxvdCBvZiBjb21tZW50cy4gIFNvcnJ5IGZvciBsYXRlIGZvbGxvd3VwIHNpbmNlIEkgaGF2ZSBq dXN0IGNvbWUgYmFjayBmcm9tIGEgdHJpcCByZWNlbnRseS4NCkkgdGhpbmsgS2VuaWNoaSBhbmQg U3RlcGhhbmUgaGFzIGFscmVhZHkgZW5nYWdlZCBpbnRvIHRoZSBkaXNjdXNzaW9uIHdpdGggeW91 IG9uIHRoZSBsaXN0Lg0KDQpJIHdpbGwgY292ZXIgeW91ciBjb21tZW50cyBiYXNlZCBvbiB0aGUg ZGlzY3Vzc2luZyBwb2ludCBpbiBhZ3JlZW1lbnQgYWZ0ZXIgYWRkcmVzc2luZyBKYW6hr3MgY29t bWVudHMuIE1hbnkgdGhhbmtzIGZvciB5b3VyIGFkZGl0aW9uYWwgaW5wdXQuDQoNCi1RaW4NCrei vP7IyzogRGF2aWQgQmFsbCBbbWFpbHRvOmRhdmliYWxsQGNpc2NvLmNvbV0NCreiy83KsbzkOiAy MDE3xOo21MIyyNUgMjM6MDgNCsrVvP7IyzogUWluIFd1OyBsM3NtQGlldGYub3JnDQrW98ziOiBS ZTogW0wzc21dIE5leHQgU3RlcCBvZiBSRkM4MDQ5DQoNCg0KSGkgUWluLA0KDQpBcyB5b3UgYXJl IHdvcmtpbmcgb24gYSBiaXMgdmVyc2lvbiwgSSBoYXZlIGEgZmV3IHF1ZXN0aW9ucyBvbiBSRkM4 MDQ5IHRoYXQgbWlnaHQgbGVhZCB0byBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0LCBhbmQgcGVyaGFw cyBzb21lIGZ1cnRoZXIgY2hhbmdlcy4NCg0KICAxLiAgVGhlIHNjb3BlIG9mIHRoZSBSRkMgc2Vl bXMgdG8gYmUgZm9jdXNlZCBvbiBpbmZvcm1hdGlvbiB0aGF0IG5lZWRzIHRvIGJlIHBhc3NlZCBm cm9tIHRoZSBjdXN0b21lciB0byB0aGUgU1AgKGUuZy4gaW4gYSAicmVxdWVzdCIpOyBob3dldmVy LCBjbGVhcmx5IGZvciB0aGUgY3VzdG9tZXIgdG8gYmUgYWJsZSB0byB1c2UgdGhlIHNlcnZpY2Us IHRoZXJlIGlzIGFsc28gaW5mb3JtYXRpb24gdGhhdCBuZWVkcyB0byBiZSBwYXNzZWQgYmFjayBm cm9tIHRoZSBTUCB0byB0aGUgY3VzdG9tZXIuICBJdCBzZWVtcyB0aGF0IHRoZSBtb2RlbCBpcyBu b3QgaW50ZW5kZWQgdG8gY292ZXIgdGhhdCAtIGlzIHRoYXQgcmlnaHQ/ICBJIHRoaW5rIHRoYXQn cyBmaW5lLCBidXQgaXQgd291bGQgYmUgaGVscGZ1bCB0byBtYWtlIHRoaXMgY2xlYXJlciAocGVy aGFwcyBpbiBzZWN0aW9uIDU/KQ0KICAyLiAgSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHRo ZSBjb25jZXB0IG9mIGEgInNpdGUiLiAgSW4gdGhlIHNpbXBsZXN0IGNhc2UsIGl0IHNlZW1zIGNs ZWFyIHRoYXQgdGhpcyBtZWFucyBhIHNpbmdsZSBwaHlzaWNhbCBsb2NhdGlvbiwgd2l0aCBvbmUg b3IgbW9yZSBjb25uZWN0aW9ucyAoc2l0ZSBuZXR3b3JrIGFjY2Vzc2VzKSB0byB0aGUgU1AuICBU aGUgUkZDIGFsc28gZGVzY3JpYmVzIGEgY2FzZSB3aGVyZSBhIHNpbmdsZSAic2l0ZSIgY291bGQg YmUgaW4gbXVsdGlwbGUgbG9jYXRpb25zIHRoYXQgYXJlIGludGVyY29ubmVjdGVkIGluZGVwZW5k ZW50bHkgb2YgdGhlIFZQTiBzZXJ2aWNlIC0gdGhlIGV4YW1wbGUgZ2l2ZW4gaXMgbXVsdGlwbGUg b2ZmaWNlcyBpbiB0aGUgc2FtZSBjaXR5LiAgRG9lcyB0aGlzIGV4dGVuZCBtb3JlIGdlbmVyYWxs eT8gIEUuZy4sIGlmIHR3byBsb2NhdGlvbnMgaW4gZGlmZmVyZW50IGNpdGllcyBhcmUgY29ubmVj dGVkIGJ5IGEgYmFja2Rvb3IgbGluaywgZG9lcyB0aGF0IG1lYW4gdGhleSdyZSB0aGUgc2FtZSBz aXRlPyAgV2hhdCBhYm91dCBpZiB0aGUgYmFja2Rvb3IgbGluayBpcyBvbmx5IHVzZWQgZm9yIGJh Y2t1cCAoaS5lLiB3aGVuIGNvbm5lY3Rpdml0eSB2aWEgdGhlIFZQTiBpcyBkb3duKT8gIElzIGEg InNpdGUiIGFsd2F5cyBjb21wbGV0ZWx5IGRpc2Nvbm5lY3RlZCAodG9wb2xvZ2ljYWxseSkgZnJv bSBvdGhlciBzaXRlcyAob3RoZXIgdGhhbiB2aWEgdGhlIFZQTiBzZXJ2aWNlKT8NCiAgMy4gIFNv bWV3aGF0IHJlbGF0ZWQsIEkgYW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2Ug YmV0d2VlbiBhIHNpdGUgd2l0aCBzdWItVlBOcyAoaS5lLiBlYWNoIHNpdGUtYWNjZXNzLWxpbmsg aXMgY29ubmVjdGVkIHRvIGEgZGlmZmVyZW50IFZQTikgdnMgdHJlYXRpbmcgaXQgYXMgdHdvIHNp dGVzLCBlYWNoIHdpdGggYSBzaW5nbGUgc2l0ZS1hY2Nlc3MtbGluay4gIFRoZSB0ZXh0IHNheXMg YSBzdWItVlBOICJpcyBzaW1pbGFyIHRvIGhhdmluZyBzZXBhcmF0ZSBzaXRlcywgYnV0IGluIHRo aXMgY2FzZSB0aGUgY3VzdG9tZXIgd2FudHMgdG8gc2hhcmUgc29tZSBwaHlzaWNhbCBjb21wb25l bnRzIHdoaWxlIG1haW50YWluaW5nIHN0cm9uZyBjb21tdW5pY2F0aW9uIGlzb2xhdGlvbiIuICBE b2VzICJ0aGlzIGNhc2UiIG1lYW4gdGhlIHN1Yi1WUE4gY2FzZSBvciB0aGUgbXVsdGlwbGUgc2l0 ZXMgY2FzZT8gIEVpdGhlciB3YXksIHRoZSBjdXN0b21lciBjb3VsZCBzaGFyZSBwaHlzaWNhbCBj b21wb25lbnRzIGFuZCBtYWludGFpbiBzdHJvbmcgaXNvbGF0aW9uLCByaWdodD8NCiAgNC4gIFVu ZGVyIHRoZSBWUE4gc2VydmljZSwgdGhlcmUgaXMgYSBsZWFmIGZvciB0aGUgY3VzdG9tZXIgbmFt ZS4gIElmIHRoZSBtb2RlbCBpcyBzdXBwb3NlZCB0byByZXByZXNlbnQgdGhlIHJlcXVlc3QgZnJv bSBhIGN1c3RvbWVyIHRvIHRoZSBTUCwgSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhlIGN1c3RvbWVy IG5hbWUgd291bGQgYmUga25vd24gb3V0LW9mLWJhbmQsIGUuZy4gZnJvbSB0aGUgQUFBIGZvciB0 aGUgcmVxdWVzdD8gIEl0IHdvdWxkIGJlIGJhZCBpZiBvbmUgY3VzdG9tZXIgY291bGQgcmVxdWVz dCB0aGluZ3MgZm9yIGFub3RoZXIgY3VzdG9tZXIgYnkgZmlsbGluZyBpbiBhIGRpZmZlcmVudCBj dXN0b21lciBuYW1lIGluIHRoZSBtb2RlbCENCiAgNS4gIEZvciBjbG91ZCBhY2Nlc3MsIGEgc2lu Z2xlIFZQTiBjYW4gY29ubmVjdCB0byBtdWx0aXBsZSBjbG91ZCBzZXJ2aWNlcywgYW5kIGZvciBl YWNoIGNsb3VkIHNlcnZpY2UgeW91IGhhdmUgdG8gc3BlY2lmeSB3aGljaCBzaXRlcyBhcmUgYXV0 aG9yaXplZCB0byBhY2Nlc3MgdGhlIGNsb3VkLiAgSXMgdGhlcmUgYSByZWFzb24gaXQgd2FzIG1v ZGVsbGVkIHRoaXMgd2F5LCByYXRoZXIgdGhhbiBoYXZpbmcgYSBzZXBhcmF0ZSBWUE4gc2Vydmlj ZSB0byBjb25uZWN0IHRvIGVhY2ggY2xvdWQgc2VydmljZT8gIElmIHRoZXJlIHdhcyBhIHNlcGFy YXRlIFZQTiBzZXJ2aWNlIGZvciBlYWNoIGNsb3VkIHNlcnZpY2UsIHRoZW4gb25seSB0aGUgcmln aHQgc2l0ZXMgd291bGQgYmUgYXR0YWNoZWQgdG8gdGhlIFZQTiBmb3IgZWFjaCBjbG91ZCwgYW5k IGl0IHdvdWxkIG5vdCBiZSBuZWNlc3NhcnkgdG8gaGF2ZSBhIHNlcGFyYXRlIGxpc3Qgb2YgYXV0 aG9yaXplZCBzaXRlcywgcmlnaHQ/DQogIDYuICBPbiB0aGF0IHN1YmplY3QsIHRoZSB5YW5nIG1v ZHVsZSBoYXMgL2wzdnBuLXN2Yy92cG4tc2VydmljZXMvdnBuLXNlcnZpY2UvY2xvdWQtYWNjZXNz ZXMvY2xvdWQtYWNjZXNzL2xpc3QtZmxhdm9yLCB3aGljaCBpcyBhIGNob2ljZSBvZiBwZXJtaXQt YW55LCBwZXJtaXQtYW55LWV4Y2VwdCBhbmQgZGVueS1hbnktZXhjZXB0LiAgSXQgYWxzbyBoYXMg L2wzdnBuLXN2Yy92cG4tc2VydmljZXMvdnBuLXNlcnZpY2UvY2xvdWQtYWNjZXNzZXMvY2xvdWQt YWNjZXNzL2F1dGhvcml6ZWQtc2l0ZXMgYW5kIC9sM3Zwbi1zdmMvdnBuLXNlcnZpY2VzL3Zwbi1z ZXJ2aWNlL2Nsb3VkLWFjY2Vzc2VzL2Nsb3VkLWFjY2Vzcy9kZW5pZWQtc2l0ZXMsIHdoaWNoIHNl ZW0gdG8gc2VydmUgdGhlIHNhbWUgcHVycG9zZS4gIFRoaXMgbG9va3MgbGlrZSBhbiBlcnJvciAt IHdhcyBvbmUgb2YgdGhlc2Ugc3VwcG9zZWQgdG8gYmUgZGVsZXRlZD8gIElmIG5vdCwgd2hhdCBp cyB0aGUgZGlmZmVyZW5jZT8gIEkgbm90aWNlZCB0aGF0IHNlY3Rpb24gNi4yLjIgb25seSBtZW50 aW9ucyB0aGUgZmlyc3Qgb25lIChsaXN0LWZsYXZvci8uLi4pLg0KICA3LiAgU3RpY2tpbmcgd2l0 aCBjbG91ZCBhY2Nlc3MsIHRoZXJlIGlzIGFuIG9wdGlvbiBmb3IgZW5hYmxpbmcgTkFUNDQuICBI b3dldmVyLCBvbmx5IGEgc2luZ2xlIGFkZHJlc3MgY2FuIGJlIHNwZWNpZmllZC4gIEZvciBzb21l IGJpZyBlbnRlcnByaXNlIGN1c3RvbWVycywgd2hlbiBOQVQgaXMgdXNlZCwgbW9yZSB0aGFuIG9u ZSBwdWJsaWMtZmFjaW5nIGFkZHJlc3MgaXMgbmVlZGVkICh0eXBpY2FsbHkgZnJvbSB0aGUgc2Ft ZSBJUCBwcmVmaXgpIC0gaXMgdGhlcmUgYSB3YXkgdG8gYWNjb21tb2RhdGUgdGhhdCBjYXNlPw0K ICA4LiAgVGhlcmUgaXMgYSAnc3ZjLW10dScgbGVhZiB1bmRlciB0aGUgc2l0ZS1uZXR3b3JrLWFj Y2VzczsgaG93ZXZlciwgaXQncyBub3QgbWVudGlvbmVkIGluIHNlY3Rpb24gNiBhbmQgaXQncyBu b3QgY2xlYXIgaG93IGl0J3MgaW50ZW5kZWQgdG8gYmUgdXNlZC4gIEF0IGxlYXN0IGZvciBJUHY0 LCBwYWNrZXRzIGxhcmdlciB0aGFuIHRoZSBNVFUgY2FuIGJlIGZyYWdtZW50ZWQgKGFsdGhvdWdo IHRoYXQgbWlnaHQgYmUgdW5kZXNpcmFibGUsIHNvIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBoYXZl IGEgcGVyLVZQTiBrbm9iIHRvIGRpc2FibGUgaXQpLiAgSSB0aGluayB0aGUgbWluaW11bSByZXF1 aXJlbWVudCBpcyB0aGF0IHRoZSBjdXN0b21lciBhbmQgdGhlIFNQIGFncmVlIG9uIHRoZSBsb3dl c3QgTVRVIGFjcm9zcyB0aGUgd2hvbGUgVlBOLCBzbyB0aGF0IHRoZSBjdXN0b21lciBjYW4gYmUg Y2VydGFpbiB0aGF0IHBhY2tldHMgc2hvcnRlciB0aGFuIHRoYXQgd2lsbCBiZSBkZWxpdmVyZWQu ICBPZiBjb3Vyc2UsIHRoZSBjdXN0b21lciBtaWdodCB1c2UgdGVjaG5pcXVlcyBsaWtlIHBhdGgg TVRVIGRpc2NvdmVyeSB0byBkZXRlcm1pbmUgdGhhdCB0aGV5IGNhbiB1c2UgYSBsYXJnZXIgTVRV IGZvciBwYXJ0aWN1bGFyIHBhdGhzLiAgSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2 ZSBzb21lIGRpc2N1c3Npb24gb2YgdGhpcyB0b3BpYyBpbiB0aGUgUkZDLg0KICA5LiAgVGhlcmUg aXMgYSBwZXItc2l0ZSBsaW1pdCBvbiB0aGUgbnVtYmVyIG9mICBJUHY0L0lQdjYgcm91dGVzICgi bWF4aW11bS1yb3V0ZXMiKSAtIGlzIHRoaXMgdGhlIG1heGltdW0gbnVtYmVyIG9mIHJvdXRlcyB0 aGF0IGNhbiBiZSBhZHZlcnRpc2VkIGJ5IHRoZSBjdXN0b21lciB0b3dhcmRzIHRoZSBTUCBhdCB0 aGF0IHNpdGU/ICBJbiBhIG11bHRpLVZQTiBjYXNlLCB3b3VsZCBpdCBiZSB1c2VmdWwgdG8gaGF2 ZSBhIHBlci1zaXRlLCBwZXItVlBOIGxpbWl0LCBlLmcuIGluIHRoZSBjYXNlIHdoZXJlIG9uZSBv ZiB0aGUgVlBOcyBpcyBhbiBleHRyYW5ldCwgdG8gbGltaXQgdGhlIG51bWJlciBvZiBwcmVmaXhl cyB0aGF0IGNhbiBiZSBhZHZlcnRpc2VkIGludG8gdGhlIGV4dHJhbmV0IGF0IHRoYXQgc2l0ZT8N CiAgMTAuIFRoZXJlIGlzIGEgcW9zLWNsYXNzaWZpY2F0aW9uLXBvbGljeSAoZWl0aGVyIHBlci1z aXRlIG9yIHBlci1zaXRlLW5ldHdvcmstYWNjZXNzKSwgd2hpY2ggZGVzY3JpYmVzIGhvdyB0byBt YXAgcGFja2V0cyB0byB0aGUgcmlnaHQgY2xhc3Mgb2Ygc2VydmljZS4gIEluIGEgc2luZ2xlLVZQ TiBjYXNlLCB0aGlzIGlzIGZpbmUsIGJ1dCBJIGFtIG5vdCBzdXJlIGhvdyB0byBpbnRlcnByZXQg aXQgd2hlbiB0aGUgc2l0ZSBpcyBhdHRhY2hlZCB0byBtdWx0aXBsZSBWUE5zLiAgVGhlIGRpZmZl cmVudCBWUE5zIG1pZ2h0IGhhdmUgZGlmZmVyZW50IGNsYXNzZXMgb2Ygc2VydmljZSwgc28gZG9l c24ndCB0aGUgY2xhc3NpZmljYXRpb24gcG9saWN5IG5lZWQgdG8gYmUgcGVyLXNpdGUgcGVyLVZQ Tiwgbm90IGp1c3QgcGVyLXNpdGU/DQogIDExLiBUaGUgcmVsYXRlZCBxb3MtcHJvZmlsZSBoYXMg Y29uc3RyYWludHMgb24gbGF0ZW5jeSBhbmQgaml0dGVyOyBob3dldmVyLCB0aGVzZSBhcHBseSB0 byBhbGwgcGFja2V0cyBpbiBhIGZsb3cuICBTbywgZm9yIGV4YW1wbGUsIGlmIHRoZXJlIHdlcmUg c2l0ZXMgaW4gTG9uZG9uLCBQYXJpcyBhbmQgU2FuIEZyYW5jaXNjbywgdGhlIHNhbWUgbGF0ZW5j eSBjb25zdHJhaW50IHdvdWxkIGFwcGx5IHRvIHBhY2tldHMgZnJvbSBMb25kb24gdG8gUGFyaXMg YW5kIHBhY2tldHMgZnJvbSBMb25kb24gdG8gU2FuIEZyYW5jaXNjbywgd2hpY2ggZG9lc24ndCBz ZWVtIHZlcnkgdXNlZnVsLiAgU2ltaWxhcmx5LCBpbiBhIG11bHRpLVZQTiBjYXNlLCB0aGUgc2Ft ZSBjb25zdHJhaW50cyB3b3VsZCBhcHBseSByZWdhcmRsZXNzIG9mIHdoaWNoIFZQTiB0aGUgcGFj a2V0IG1hcHMgdG8uICBUaGlzIHR5cGUgb2YgY29uc3RyYWludCB3b3VsZCBub3JtYWxseSBiZSBp biBhbiBTTFMsIGJ1dCBJIHRob3VnaHQgaW4gZ2VuZXJhbCB0aGUgYXBwcm9hY2ggd2FzIHRvIGF2 b2lkIHRyeWluZyB0byBzcGVjaWZ5IGFuIFNMUyBpbiB0aGUgbW9kZWw/DQogIDEyLiBPbiBzaW1p bGFyIGxpbmVzLCBpbiB0aGUgcW9zLXByb2ZpbGUgdGhlcmUgaXMgYSBndWFyYW50ZWVkLWJhbmR3 aWR0aCwgd2hpY2ggY2FuIGVpdGhlciBiZSBmb3IganVzdCB0aGUgYWNjZXNzLCBvciBjYW4gYmUg ZW5kLXRvLWVuZC4gIEhvdyBzaG91bGQgYW4gZW5kLXRvLWVuZCBiYW5kd2lkdGggZ3VhcmFudGVl IGJlIGludGVycHJldGVkIGlmIHRoZSBWUE4gaGFzIG1vcmUgdGhhbiB0d28gc2l0ZXM/ICBPciBk b2VzIGl0IG9ubHkgbWFrZSBzZW5zZSBmb3IgYSBQMlAgY2FzZT8NCiAgMTMuIExvdHMgb2YgcXVl c3Rpb25zIGFib3V0IHRoZSByb3V0aW5nLXByb3RvY29sczoNCiAgICAgKiAgIFdoZW4gdGhlIHJv dXRpbmcgcHJvdG9jb2wgaXMgImRpcmVjdCIsIHRoZSBTUCByb3V0ZXMgdHJhZmZpYyB0b3dhcmRz IHRoZSBwcmVmaXggc3BlY2lmaWVkIGJ5IHRoZSBjb25uZWN0aW9uIGFkZHJlc3M7IGhvd2V2ZXIs IG9uZSB3b3VsZCBleHBlY3QgdGhhdCB0aGV5IGFsd2F5cyBkbyB0aGlzIHJlZ2FyZGxlc3Mgb2Yg d2hhdCBvdGhlciByb3V0aW5nIHByb3RvY29sIGlzIGluIHVzZSwgcmlnaHQ/ICBTbywgd2hhdCBp cyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHNwZWNpZnlpbmcgcm91dGluZyBwcm90b2NvbCAiZGly ZWN0IiwgYW5kIGxlYXZpbmcgdGhlIHJvdXRpbmcgcHJvdGNvbCBsaXN0IGVtcHR5Pw0KICAgICAq ICAgVGhlIHB1cnBvc2Ugb2YgVlJSUCBpcyB0byBiZSBvcGFxdWUgdG8gdGhlIGN1c3RvbWVyIC0g c28gaXQncyBub3QgY2xlYXIgd2h5IHRoZSBjdXN0b21lciB3b3VsZCBleHBsaWNpdGx5IHJlcXVl c3QgdGhpcz8gIElzIHRoZSBpbnRlbnQgdG8gY2FwdHVyZSB0aGF0IHRoZSBjdXN0b21lciB3YW50 cyB0byBlbnN1cmUgdGhlcmUgaXMgcmVkdW5kYW5jeSBvZiB0aGUgYWNjZXNzIGxpbmsgYXQgTDI/ IElmIHNvLCBwZXJoYXBzIGl0IHdvdWxkIGJlIGJldHRlciBoYW5kbGVkIGJ5IGhhdmluZyBzb21l IHNvcnQgb2YgYWNjZXNzIGNvbnN0cmFpbnQgZm9yICJsMi1kaXZlcnNlIj8NCiAgICAgKiAgIEZv ciBPU1BGLCBkb2Vzbid0IHNvbWUgaW5mb3JtYXRpb24gb24gdGhlIHRpbWVycyAoaGVsbG8gaW50 ZXJ2YWwsIGRlYWQgaW50ZXJ2YWwsIHJldHJhbnNtaXQgaW50ZXJ2YWwpIG5lZWQgdG8gYmUgZXhj aGFuZ2VkLCBzbyB0aGF0IHRoZSBjdXN0b21lciBhbmQgU1AgY2FuIGNvbmZpZ3VyZSB0aGVpciBk ZXZpY2VzIGluIHN1Y2ggYSB3YXkgdGhhdCB0aGV5IHdvbid0IHRpbWUgZWFjaCBvdGhlciBvdXQ/ ICBQZXJoYXBzIHRoZSBpbnRlbnQgaXMgdGhhdCB0aGUgU1Agc3BlY2lmaWVzIHRoZXNlLCBhbmQg aXQncyBub3QgY292ZXJlZCBpbiB0aGUgbW9kZWwgKGdvaW5nIGJhY2sgdG8gbXkgZmlyc3QgcXVl c3Rpb24pPyAgSWYgc28sIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBtYWtlIHRoaXMgZXhwbGljaXQu DQogICAgICogICBGb3IgT1NQRiwgYSBtZXRyaWMgY2FuIGJlIHNwZWNpZmllZCAtIHRoZSBvbmx5 IGRlc2NyaXB0aW9uIGlzICJNZXRyaWMgb2YgdGhlIFBFLUNFIGxpbmsiLiAgSG93IGlzIHRoaXMg aW50ZW5kZWQgdG8gYmUgdXNlZD8gIEhvdyBkb2VzIHRoaXMgcmVsYXRlIHRvIHRoZSAnYWNjZXNz LXByaW9yaXR5JyBmb3IgdGhlIHNpdGUtbmV0d29yay1hY2Nlc3Nlcywgd2hpY2ggaXMgc3VwcG9z ZWQgdG8gYmUgdXNlZCB0byBpbmZsdWVuY2UgbG9hZC1zaGFyaW5nIGFuZCBhY3RpdmUvc3RhbmRi eT8NCiAgICAgKiAgIEZvciBCR1AsIHRoZXJlIGlzIGFuIEFTIG51bWJlciwgYnV0IGlzIGl0IHN1 cHBvc2VkIHRvIGJlIHRoZSBjdXN0b21lcidzIEFTIG51bWJlciBvciB0aGUgU1AncyBBUyBudW1i ZXI/ICBUaGUgZGVzY3JpcHRpb24ganVzdCBzYXlzICJBUyBOdW1iZXIiLCB3aGljaCBpcyBub3Qg dmVyeSBpbGx1bWluYXRpbmcuDQogICAgICogICBBbHNvIEkgdGhpbmsgdGhlcmUgaXMgYSBsb3Qg bW9yZSB0aGF0IHdvdWxkIG5lZWQgdG8gYmUgYWdyZWVkIG9uIGZvciBCR1A7IGZvciBpbnN0YW5j ZSwgdGhlIHRpbWVycyAoc2ltaWxhciB0byB0aGUgT1NQRiBjYXNlKSwgYXV0aGVudGljYXRpb24g KGUuZy4gTUQ1K3Bhc3N3b3JkKSwgd2hldGhlciB0aGUgU1Agd2lsbCBhcHBseSAiQVMgb3ZlcnJp ZGUiIGJlaGF2aW91ciwgZXRjLg0KICAgICAqICAgRm9yIGR1YWwtc3RhY2sgQkdQLCB0aGUgdGV4 dCBzYXlzIGl0IGlzIHVwIHRvIHRoZSBTUCB0byBkZWNpZGUgd2hldGhlciB0byB1c2Ugb25lIHNl c3Npb24gb3IgdHdvIHNlc3Npb25zIC0gYnV0IGNsZWFybHkgdGhlIGN1c3RvbWVyIG5lZWRzIHRv IGtub3cgdGhpcyB0b28gc28gdGhhdCB0aGV5IGNhbiBjb25maWd1cmUgdGhlaXIgZGV2aWNlcyBh Y2NvcmRpbmdseS4gIElzIHRoYXQgaW50ZW5kZWQgdG8gYmUgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhlIG1vZGVsPyAgSXQgd291bGQgYmUgdXNlZnVsIHRvIGNsYXJpZnkgaXQuDQogICAgICogICBJ dCBhbHNvIHNheXMgdGhhdCB0aGUgc2Vzc2lvbiBhZGRyZXNzaW5nIGlzIGRlcml2ZWQgZnJvbSB0 aGUgY29ubmVjdGlvbiBwYXJhbWV0ZXJzIC0gdGhpcyBpcyBhIGNvbW1vbiBjYXNlLCBidXQgbm90 IHRoZSBvbmx5IHdheSB0byBkbyBpdC4gIEZvciBleGFtcGxlLCBpZiB0aGVyZSBhcmUgbXVsdGlw bGUgc2l0ZS1uZXR3b3JrLWFjY2Vzc2VzLCB0aGVuIHRoZSBTUCBtYXkgZGVjaWRlIHRvIHVzZSBh IHNpbmdsZSBCR1Agc2Vzc2lvbiBiZXR3ZWVuIGxvb3BiYWNrcywgdXNpbmcgRUJHUC1tdWx0aWhv cCwgcmF0aGVyIHRoYW4gYSBzZXBhcmF0ZSBCR1Agc2Vzc2lvbiBvbiBlYWNoIHNpdGUtbmV0d29y ay1hY2Nlc3MuICBDYW4gdGhlIG1vZGVsIGFjY29tb2RhdGUgdGhpcyBjYXNlPw0KICAgICAqICAg Rm9yIHN0YXRpYyByb3V0aW5nLCBlYWNoIHByZWZpeCBoYXMgYSBtYW5kYXRvcnkgbmV4dGhvcDsg aG93ZXZlciwgZm9yIFAyUCBMMiB0ZWNobm9sb2dpZXMgKGUuZy4gUFBQLCBBVE0pLCB0aGUgbmV4 dGhvcCBtaWdodCBub3QgYmUgbmVlZGVkLCByaWdodD8NCiAgMTQuIExvdHMgb2YgcGFyYW1ldGVy cyBjYW4gYmUgc3BlY2lmaWVkIGVpdGhlciBvbiB0aGUgc2l0ZSBvciBvbiB0aGUgc2l0ZS1uZXR3 b3JrLWFjY2Vzcy4gIEhvd2V2ZXIsIEJGRCBjYW4gb25seSBiZSBzcGVjaWZpZWQgb24gdGhlIHNp dGUtbmV0d29yay1hY2Nlc3MuICBJcyB0aGVyZSBhIHJlYXNvbiBmb3IgdGhpcz8gIEkgd291bGQg aGF2ZSB0aG91Z2h0IGlmIHlvdSB3YW50IEJGRCBvbiBvbmUgc2l0ZS1uZXR3b3JrLWFjY2Vzcywg eW91IHByb2JhYmx5IHdhbnQgaXQgb24gYWxsIG9mIHRoZW0sIHdpdGggdGhlIHNhbWUgcGFyYW1l dGVycywgc28gaGF2aW5nIHRoZSBwb3NzaWJpbGl0eSBvZiBzcGVjaWZ5aW5nIGl0IG9uY2UgdW5k ZXIgdGhlIHNpdGUgd291bGQgc2VlbSB1c2VmdWwuDQogIDE1LiBTb21lIHF1ZXN0aW9ucyBhYm91 dCB0aGUgSVB2NC9JUHY2IGNvbm5lY3Rpb24gZm9yIGVhY2ggc2l0ZS1uZXR3b3JrLWFjY2VzczoN CiAgICAgKiAgIFdoZW4gREhDUCBpcyB1c2VkLCB0aGUgcHJvdmlkZXIgYWRkcmVzcyBhbmQgbWFz ayBhcmVuJ3Qgc3BlY2lmaWVkIC0gYnV0IGRvZXNuJ3QgdGhlIGN1c3RvbWVyIG5lZWQgdG8ga25v dyB0aGlzLCBzbyBhcyB0byBhdm9pZCBhbGxvY2F0aW5nIGFkZHJlc3NlcyB3aXRoaW4gdGhhdCBw cmVmaXggdG8gdGhlaXIgaW50ZXJuYWwgZGV2aWNlcz8gIE9yIGRvZXMgdGhpcyBhZ2FpbiBmYWxs IGludG8gdGhlIGNhdGVnb3J5IG9mIGluZm9ybWF0aW9uIHBhc3NlZCBmcm9tIHRoZSBTUCB0byB0 aGUgY3VzdG9tZXIsIGFuZCBoZW5jZSBub3QgaW4gdGhlIHNjb3BlIG9mIHRoZSBtb2RlbD8NCiAg ICAgKiAgIFNpbWlsYXJseSwgd2hlbiBESENQIGlzIHVzZWQsIHRoZSBjdXN0b21lciBtYXkgc3Rp bGwgd2FudCBzb21lIHN0YXRpY2FsbHktYXNzaWduZWQgaG9zdHMgb24gdGhhdCBzdWJuZXQgKGUu Zy4gZm9yIHNlcnZlcnMgZXRjKS4gIFRoZXJlIGlzIGEgbGVhZiBmb3Igc2F5aW5nIGhvdyBtYW55 IERIQ1AgYWRkcmVzc2VzIGFyZSBiZWluZyByZXF1ZXN0ZWQsIGJ1dCBJIHRoaW5rIHRoZSBjdXN0 b21lciB3b3VsZCBhbHNvIG5lZWQgdG8ga25vdyB3aGljaCBhZGRyZXNzZXMsIHNvIHRoYXQgdGhl eSBjYW4gYXNzaWduIG90aGVyIGFkZHJlc3NlcyBvbiB0aGF0IHN1Ym5ldCBzdGF0aWNhbGx5LCBy aWdodD8NCiAgICAgKiAgIFdoZW4gREhDUC1SZWxheSBpcyB1c2VkLCBkb2VzIGl0IG1ha2Ugc2Vu c2UgdG8gaGF2ZSBhIG11bHRpLVZQTiBjYXNlPyAgSSdtIG5vdCBzdXJlIGhvdyB0aGUgU1Agd291 bGQga25vdyB3aGljaCBWUE4gdG8gZm9yd2FyZCB0aGUgREhDUCByZXF1ZXN0cyBvdmVyIGluIHRo aXMgY2FzZS4NCiAgICAgKiAgIEZvciBJUHY2IGNvbm5lY3Rpb24sIGlzIHRoZXJlIGEgY2FzZSB3 aGVyZSBvbmx5IGxpbmstbG9jYWwgYWRkcmVzc2VzIGFyZSB1c2VkPw0KICAxNi4gVW5kZXIgdGhl IHNpdGUtbmV0d29yay1hY2Nlc3MsIHRoZXJlIGlzIGEgc3ZjLWlucHV0LWJhbmR3aWR0aCBhbmQg c3ZjLW91dHB1dC1iYW5kd2lkdGguICBTZWN0aW9uIDYuMTIuMSBzYXlzIHRoYXQgaW5wdXQvb3V0 cHV0IGlzIGZyb20gdGhlIHNpdGUncyBwZXJzcGVjdGl2ZSwgaS5lLiAiaW5wdXQgYmFuZHdpZHRo IiBtZWFucyBkb3dubG9hZCBmcm9tIHRoZSBTUCB0b3dhcmRzIHRoZSBzaXRlLCBhbmQgIm91dHB1 dCBiYW5kd2lkdGgiIG1lYW5zIHVwbG9hZCBmcm9tIHRoZSBzaXRlIHRvd2FyZHMgdGhlIFNQLiAg SG93ZXZlciwgdGhlIGRlc2NyaXB0aW9ucyBvZiB0aGUgbGVhdmVzIHdpdGhpbiB0aGUgbW9kdWxl IHNheSB0aGUgb3Bwb3NpdGU6IHN2Yy1pbnB1dC1iYW5kd2lkdGggaXMgIkZyb20gdGhlIFBFJ3Mg cGVyc3BlY3RpdmUsIHRoZSBzZXJ2aWNlIGlucHV0IGJhbmR3aWR0aCBvZiB0aGUgY29ubmVjdGlv bi4iIGFuZCBsaWtld2lzZSBmb3Igb3V0cHV0LiAgVG8gbXkgbWluZCwgZXhwcmVzc2luZyB0aGlz IGZyb20gdGhlIFNQJ3MgcGVyc3BlY3RpdmUgbWFrZXMgbW9yZSBzZW5zZSAoaS5lLiwgaXQgaXMg aW5wdXQgdG8gb3Igb3V0cHV0IGZyb20gdGhlIFZQTiBzZXJ2aWNlKSAtIGJ1dCBlaXRoZXIgd2F5 LCB0aGUgZG9jdW1lbnQgc2hvdWxkIGJlIGNvbnNpc3RlbnQgYW5kIG5vdCBjb250cmFkaWN0IGl0 c2VsZi4gIE5vdGUgdGhhdCB0aGVzZSBsZWF2ZXMgYXJlIGFsc28gcmVmZXJlZCB0byBpbiBzZWN0 aW9uIDYuMTIuMi4yIGZvciB0aGUgUW9TIHByb2ZpbGUgLSB0aGF0IHRleHQgbWlnaHQgYWxzbyBi ZSBhZmZlY3RlZCB3aGVuIHJlc29sdmluZyB0aGUgY29uZmxpY3QuDQogIDE3LiBUaGUgYWNjZXNz LXByaW9yaXR5IGxlYWYgaXMgc3VwcG9zZWQgdG8gYmUgdXNlZCB0byBkZWZpbmUgYSBwcmVmZXJl bmNlIGZvciBsb2FkLWJhbGFuY2luZyBvciBhY3RpdmUvc3RhbmRieSB3aGVuIHRoZXJlIGFyZSBt dWx0aXBsZSBzaXRlLW5ldHdvcmstYWNjZXNzZXMuICBIb3dldmVyLCBpdCB3YXNuJ3QgY2xlYXIg dG8gbWUgd2hldGhlciB0aGlzIHdhcyBpbnRlbmRlZCB0byBhcHBseSB0byBpbmdyZXNzIHRyYWZm aWMsIGVncmVzcyB0cmFmZmljLCBvciBib3RoOyBvciBob3cgaXQgcmVsYXRlcyB0byB0aGUgcm91 dGluZyBwcm90b2NvbCBtZXRyaWNzL2Nvc3RzLiAgV2hlbiB0aGUgY3VzdG9tZXIgc2VuZHMgdHJh ZmZpYyB0b3dhcmRzIHRoZSBTUCwgdGhleSBjYW4gY2hvc2Ugd2hpY2hldmVyIHNpdGUtbmV0d29y ay1hY2Nlc3MgdGhleSBsaWtlLCBhbmQgdGhlIFNQIHNob3VsZCBkZWxpdmVyIHRoZSB0cmFmZmlj LCBzbyBpdCBzZWVtcyB0aGF0IG5vdGhpbmcgbmVlZHMgdG8gYmUgc3BlY2lmaWVkIGluIHRoYXQg Y2FzZTsgaWYgc28sIHRoZSBhY2Nlc3MtcHJpb3JpdHkgd291bGQgb25seSBhcHBseSB0byB0cmFm ZmljIGZsb3dpbmcgZnJvbSB0aGUgU1AgdG8gdGhlIGN1c3RvbWVyLiAgSG93ZXZlciwgYXNzdW1p bmcgYSBkeW5hbWljIHJvdXRpbmcgcHJvdG9jb2wgaXMgdXNlZCwgdGhlIGN1c3RvbWVyIG91Z2h0 IHRvIGJlIGFibGUgdG8gaW5mbHVlbmNlIHRoYXQgYnkgYWR2ZXJ0aXNpbmcgZGlmZmVyZW50IG1l dHJpY3Mgb24gdGhlIGRpZmZlcmVudCBzaXRlLW5ldHdvcmstYWNjZXNzZXMgKHByb3ZpZGVkIHRo ZSBTUCBob25vdXJzIHRoZXNlKS4gIFRoZSBvbmx5IG1vcmUgY29tcGxleCBjYXNlIEkgY291bGQg dGhpbmsgb2YgaXMgd2hlcmUgdGhlcmUncyBhIGRlc2lyZSB0byBlbnN1cmUgdGhhdCB0cmFmZmlj IGFsd2F5cyBmbG93cyBiaWRpcmVjdGlvbmFsbHkgb24gdGhlIHNhbWUgbGluayAtIGJ1dCB0aGVu LCBJIGNvdWxkbid0IGZpZ3VyZSBvdXQgaG93IHRoZSBhY2Nlc3MtcHJpb3JpdHkgY291bGQgaGVs cCB3aXRoIHRoYXQuICBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KDQpTb3JyeSBmb3IgaGF2aW5n IHNvIG1hbnkgcXVlc3Rpb25zIQ0KDQpUaGFua3MgaW4gYWR2YW5jZSwNCg0KDQoNCiAgICBEYXZp ZA0KDQpPbiAwOS8wNS8yMDE3IDE0OjU3LCBRaW4gV3Ugd3JvdGU6DQpEZWFyIEwzU00gbGlzdCwN Cg0KQXMgeW91IHNhdywgSmFuIGRpZCBhIHZlcnkgZ29vZCByZXZpZXcgb2YgdGhlIEwzU00gWUFO RyBtb2RlbCwgYW5kIHRoZXJlIGhhcw0KYmVlbiBhIGxpdHRsZSBkaXNjdXNzaW9uIG9uIHRoaXMg bGlzdC4NCg0KSSBhbSBwcmVwYXJpbmcgYSBiaXMgZHJhZnQgdG8gaW5jbHVkZSBhbGwgb2YgdGhl IGNvbW1lbnRzLiBUaGUgcGxhbiBpczoNCi0gSSBzaG93IHRoZSBkcmFmdCB0byBKYW4gYW5kIHRo ZSBhdXRob3JzIG9mIHRoZSBSRkMNCi0gSSBwb3N0IHRoZSBkcmFmdA0KLSBXZSByZXZpZXcgaXQg b24gdGhpcyBsaXN0DQotIFdlIGFzayBCZW5vaXQgdG8gQUQgc3BvbnNvciBpdA0KDQpJIGhvcGUg dG8gaGF2ZSB0aGUgcmV2aXNpb24gcmVhZHkgdmVyeSBzb29uLg0KDQpSZWdhcmRzLA0KUWluDQoN Cg0KU2VudCBmcm9tIEhVQVdFSSBBbnlPZmZpY2UNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KTDNzbSBtYWlsaW5nIGxpc3QNCg0KTDNz bUBpZXRmLm9yZzxtYWlsdG86TDNzbUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sM3NtDQoNCg0KDQotLQ0KDQpEYXZpZCBCYWxsDQoNCjxkYXZpYmFs bEBjaXNjby5jb20+PG1haWx0bzpkYXZpYmFsbEBjaXNjby5jb20+DQo= --_000_B8F9A780D330094D99AF023C5877DABA9A976E04nkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thanks Dav= id for taking a stab into RFC8049 and provide a lot of comments.  Sorr= y for late followup since I have just come back from a trip recently.<= /o:p>

I think Ke= nichi and Stephane has already engaged into the discussion with you on the = list.

 = ;

I will cov= er your comments based on the discussing point in agreement after addressin= g Jan=A1=AFs comments. Many thanks for your additional input.

 = ;

-Qin<= /o:p>

=B7=A2=BC=FE=C8=CB:<= /b> David Ball [mailto:daviball@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA6=D4=C22=C8=D5 23:08
=CA=D5=BC=FE=C8=CB: Qin Wu; l3sm@ietf.org
=D6=F7=CC=E2: Re: [L3sm] Next Step of RFC8049

 

Hi Qin,

As you are working on a bis version, I have a few q= uestions 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 informatio= n that needs to be passed from the customer to the SP (e.g. in a "requ= est"); 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 "sit= e".  In the simplest case, it seems clear that this means a singl= e physical location, with one or more connections (site network accesses) t= o the SP.  The RFC also describes a case where a single "site" could be in multiple locations that are interconne= cted independently of the VPN service - the example given is multiple offic= es 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 t= he backdoor link is only used for backup (i.e. when connectivity via the VP= N is down)?  Is a "site" always completely disconnected (top= ologically) from other sites (other than via the VPN service)?
  3. Somewhat related, I am trying to understand the differ= ence 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-ac= cess-link.  The text says a sub-VPN "is similar to having separate sites, but in this case the customer w= ants to share some physical components while maintaining strong communicati= on 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 custome= r name.  If the model is supposed to represent the request from a cust= omer to the SP, I would have thought the customer name would be known out-o= f-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 modelle= d this way, rather than having a separate VPN service to connect to each cloud service?  If there was a separat= e VPN service for each cloud service, then only the right sites would be at= tached to the VPN for each cloud, and it would not be necessary to have a s= eparate list of authorized sites, right?
  6. On that subject, the yang module has /l3vpn-svc/vpn-se= rvices/vpn-service/cloud-accesses/cloud-access/list-flavor, which is a choi= ce 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 erro= r - was one of these supposed to be deleted?  If not, what is the diff= erence?  I noticed that section 6.2.2 only mentions the first one (list-flavor/...).
  7. Sticking with cloud access, there is an option for ena= bling NAT44.  However, only a single address can be specified.  F= or some big enterprise customers, when NAT is used, more than one public-fa= cing 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-acces= s; however, it's not mentioned in section 6 and it's not clear how it's int= ended 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 lowes= t MTU across the whole VPN, so that the customer can be certain that packet= s shorter than that will be delivered.  Of course, the customer might use techniques like path MTU discovery to de= termine 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 ro= utes that can be advertised by the customer towards the SP at that site?&nb= sp; 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 extr= anet, to limit the number of prefixes that can be advertised into the extra= net 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 righ= t 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 differen= t classes of service, so doesn't the classification policy need to be per-s= ite 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 examp= le, if there were sites in London, Paris and San Francisco, the same latenc= y constraint would apply to packets from London to Paris and packets from London to San Francisco, which doesn't se= em 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 guaran= teed-bandwidth, which can either be for just the access, or can be end-to-e= nd.  How should an end-to-end bandwidth guarantee be interpreted if th= e 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 S= P routes traffic towards the prefix specified by the connection address; ho= wever, one would expect that they always do this regardless of what other r= outing 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 &q= uot;l2-diverse"?
    3. For OSPF, doesn't some information on the timers (hell= o interval, dead interval, retransmit interval) need to be exchanged, so th= at 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 mod= el (going back to my first question)?  If so, it would be useful to ma= ke this explicit.
    4. For OSPF, a metric can be specified - the only descrip= tion 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 ju= st 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), au= thentication (e.g. MD5+password), whether the SP will apply "AS ov= erride" behaviour, etc.
    7. For dual-stack BGP, the text says it is up to the SP t= o decide whether to use one session or two sessions - but clearly the custo= mer needs to know this too so that they can configure their devices accordi= ngly.  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 fr= om 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, t= hen 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 c= ase?
    9. For static routing, each prefix has a mandatory nextho= p; 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 h= ave thought if you want BFD on one site-network-access, you probably want it on all of them, with the same parameters, so having t= he 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 al= locating addresses within that prefix to their internal devices?  Or d= oes 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 w= ant some statically-assigned hosts on that subnet (e.g. for servers etc).&n= bsp; 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 s= ubnet 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 forwa= rd the DHCP requests over in this case.
    4. For IPv6 connection, is there a case where only link-l= ocal addresses are used?
  16. Under the site-network-access, there is a svc-input-ba= ndwidth and svc-output-bandwidth.  Section 6.12.1 says that input/outp= ut is from the site's perspective, i.e. "input bandwidth" means d= ownload 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-inpu= t-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 do= cument should be consistent and not contradict itself.  Note that thes= e leaves are also refered to in section 6.12.2.2 for the QoS profile - that text might also be affected when resol= ving the conflict.
  17. The access-priority leaf is supposed to be used to def= ine a preference for load-balancing or active/standby when there are multip= le 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 chos= e whichever site-network-access they like, and the SP should deliver the tr= affic, 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 d= ynamic 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).&nb= sp; The only more complex case I could think of is where there's a desire t= o ensure that traffic always flows bidirectionally on the same link - but t= hen, I couldn't figure out how the access-priority could help with that.  Am I missing something?
    18. =

Sorry for having so many questions!

Thanks in advance,

 

    David

=  

On 09/05/2017 14:57, Qin Wu wro= te:

Dear L3SM list,

As you saw, Jan did a very good rev= iew of the L3SM YANG model, and there&nb= sp;has
been a little discussion on this list.

I am preparing a bis draft to include&nb= sp;all of the comments. The plan is:
- I show the draft to Jan and the&n= bsp;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&n= bsp;soon.

Regards,
Qin


Sent from HUAWEI AnyOffice




_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm




-- 
David Ball
<davibal=
l@cisco.com>
--_000_B8F9A780D330094D99AF023C5877DABA9A976E04nkgeml513mbxchi_-- From nobody Thu Jun 22 05:13:45 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93558128BA2 for ; Thu, 22 Jun 2017 05:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S0FEJ4RZefB for ; Thu, 22 Jun 2017 05:13:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E987D126D45 for ; Thu, 22 Jun 2017 05:13:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPQ13041; Thu, 22 Jun 2017 12:13:37 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 22 Jun 2017 13:13:36 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 22 Jun 2017 20:13:32 +0800 From: Qin Wu To: "l3sm@ietf.org" CC: "Jan Lindblad (jlindbla)" , "adrian@olddog.co.uk" , "Benoit Claise (bclaise)" Thread-Topic: I-D Action: draft-wu-l3sm-rfc8049bis-00.txt Thread-Index: AQHS60/al72SWIj7YEiowZPt9ZDOi6IwyWmA Date: Thu, 22 Jun 2017 12:13:31 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.594BB472.009C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 006cdca54fc730937f944d9a59686238 Archived-At: Subject: Re: [L3sm] I-D Action: draft-wu-l3sm-rfc8049bis-00.txt X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 12:13:42 -0000 SGksTDNTTWVyczoNClRoYW5rIEphbiBmb3IgZXhjZWxsZW50IFlBTkcgZG9jdG9yIHJldmlldyBh bmQgdmFsdWFibGUgaW5wdXRzIGJhc2VkIG9uIFNlcnZpY2UgTW9kZWwgZGVwbG95bWVudCBleHBl cmllbmNlLg0KVGhhbmtzIGZvciBMM1NNIGRlc2lnbiB0ZWFtIHRvIGVuZ2FnZSBpbiB0aGUgZGlz Y3Vzc2lvbiBvbiB0aGUgbGlzdCBhbmQgaGVscCBhZGRyZXNzIGFsbCBvZiBjb21tZW50cy4NCkhl cmUgaXMgdGhlIGluaXRpYWwgdmVyc2lvbiBvZiBSRkM4MDQ5YmlzLg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXd1LWwzc20tcmZjODA0OWJpcy0wMA0KSmFuLCBwbGVhc2UgcmV2 aWV3IGl0IGFuZCBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgYWRkaXRpb25hbCBjb21tZW50 cy4NCg0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IEktRC1Bbm5vdW5jZSBbbWFp bHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZw0Kt6LLzcqxvOQ6IDIwMTfE6jbUwjIyyNUgMjA6MDUNCsrVvP7IyzogaS1kLWFubm91 bmNlQGlldGYub3JnDQrW98ziOiBJLUQgQWN0aW9uOiBkcmFmdC13dS1sM3NtLXJmYzgwNDliaXMt MDAudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQoNCiAgICAgICAgVGl0bGUgICAg ICAgICAgIDogWUFORyBEYXRhIE1vZGVsIGZvciBMM1ZQTiBTZXJ2aWNlIERlbGl2ZXJ5DQogICAg ICAgIEF1dGhvcnMgICAgICAgICA6IFFpbiBXdQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBT dGVwaGFuZSBMaXRrb3dza2kNCiAgICAgICAgICAgICAgICAgICAgICAgICAgTHVpcyBUb21vdGFr aQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBLZW5pY2hpIE9nYWtpDQoJRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtd3UtbDNzbS1yZmM4MDQ5YmlzLTAwLnR4dA0KCVBhZ2VzICAgICAgICAgICA6 IDE3NQ0KCURhdGUgICAgICAgICAgICA6IDIwMTctMDYtMjINCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgdGhhdCBjYW4gYmUgdXNlZCBmb3IN CiAgIGNvbW11bmljYXRpb24gYmV0d2VlbiBjdXN0b21lcnMgYW5kIG5ldHdvcmsgb3BlcmF0b3Jz IGFuZCB0byBkZWxpdmVyDQogICBhIExheWVyIDMgcHJvdmlkZXItcHJvdmlzaW9uZWQgVlBOIHNl cnZpY2UuICBUaGlzIGRvY3VtZW50IGlzIGxpbWl0ZWQNCiAgIHRvIEJHUCBQRS1iYXNlZCBWUE5z IGFzIGRlc2NyaWJlZCBpbiBSRkNzIDQwMjYsIDQxMTAsIGFuZCA0MzY0LiAgVGhpcw0KICAgbW9k ZWwgaXMgaW50ZW5kZWQgdG8gYmUgaW5zdGFudGlhdGVkIGF0IHRoZSBtYW5hZ2VtZW50IHN5c3Rl bSB0bw0KICAgZGVsaXZlciB0aGUgb3ZlcmFsbCBzZXJ2aWNlLiAgSXQgaXMgbm90IGEgY29uZmln dXJhdGlvbiBtb2RlbCB0byBiZQ0KICAgdXNlZCBkaXJlY3RseSBvbiBuZXR3b3JrIGVsZW1lbnRz LiAgVGhpcyBtb2RlbCBwcm92aWRlcyBhbiBhYnN0cmFjdGVkDQogICB2aWV3IG9mIHRoZSBMYXll ciAzIElQIFZQTiBzZXJ2aWNlIGNvbmZpZ3VyYXRpb24gY29tcG9uZW50cy4gIEl0IHdpbGwNCiAg IGJlIHVwIHRvIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSB0byB0YWtlIHRoaXMgbW9kZWwgYXMgaW5w dXQgYW5kIHVzZQ0KICAgc3BlY2lmaWMgY29uZmlndXJhdGlvbiBtb2RlbHMgdG8gY29uZmlndXJl IHRoZSBkaWZmZXJlbnQgbmV0d29yaw0KICAgZWxlbWVudHMgdG8gZGVsaXZlciB0aGUgc2Vydmlj ZS4gIEhvdyB0aGUgY29uZmlndXJhdGlvbiBvZiBuZXR3b3JrDQogICBlbGVtZW50cyBpcyBkb25l IGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudC4NCg0KICAgSWYgYXBwcm92ZWQsIHRo aXMgZG9jdW1lbnQgb2Jzb2xldGVzIFJGQyA4MDQ5LiAgVGhlIGNoYW5nZXMgYXJlIGENCiAgIHNl cmllcyBvZiBzbWFsbCBmaXhlcyB0byB0aGUgWUFORyBtb2R1bGUsIGFuZCBzb21lIGNsYXJpZmlj YXRpb25zIHRvDQogICB0aGUgdGV4dC4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXd1LWwzc20tcmZjODA0OWJpcy8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1 LWwzc20tcmZjODA0OWJpcy0wMA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC13dS1sM3NtLXJmYzgwNDliaXMtMDANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJLUQtQW5ub3VuY2Ug bWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJbnRlcm5ldC1EcmFmdCBkaXJlY3Rvcmll czogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcv aWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K From nobody Thu Jun 22 05:25:51 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B141129405 for ; Thu, 22 Jun 2017 05:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e4IcAfKs_to for ; Thu, 22 Jun 2017 05:25:46 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834D01287A0 for ; Thu, 22 Jun 2017 05:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31072; q=dns/txt; s=iport; t=1498134345; x=1499343945; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=e48JbZo+mKys3eyitPgUaus+JVgSn58L1aUlwAf3DQ8=; b=TML5FigAZYF30HxXcIdSUHq1rcbpnesg6zR4nWYybpFM6CwmEDq6YZdK IUd9SSPa4TlTNK4Rn2Y9tMbt+wMT2UKPK1vrgX5m6yMQaQXUhLLxdul8M ZlTXjOXXvyzthw7Fkbok/YESbckZZ4P3rsK3LH1cNIzoYdTNejrZSc17g g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAACatUtZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyuBD4ENg2yKGXOQa3OVBYIOAyELhXgCgzwYAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECAQEBGAkVLwcXBAsRBAEBAQICFA8DAgInHwkIBgEMBgIBARUCigkIE?= =?us-ascii?q?Ko0EYEjgiaLZQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFYoFfASuBbVg0gTy?= =?us-ascii?q?CdBYBAwo8BiKCRYJhBYlIhnmBXYxFiDmCN4hyggmDRIIEg0uGc4xMiEofOIEKM?= =?us-ascii?q?CEIGxVJhQ0BBAcQgWUCPzaHHgElghkBAQE?= X-IronPort-AV: E=Sophos;i="5.39,373,1493683200"; d="scan'208";a="695330566" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2017 12:25:40 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5MCPbRQ015403; Thu, 22 Jun 2017 12:25:39 GMT To: stephane.litkowski@orange.com, "Ogaki, Kenichi" , "'Qin Wu'" , "l3sm@ietf.org" References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: David Ball Message-ID: <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> Date: Thu, 22 Jun 2017 13:25:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 12:25:50 -0000 Thanks Stephane - responses in line (marked [DB3]): On 21/06/2017 10:56, stephane.litkowski@orange.com wrote: > Hi, > > Please find some comments inline (marked with [SLI]) > > > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Tuesday, June 20, 2017 19:33 > To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org > Subject: Re: [L3sm] Next Step of RFC8049 > > Thanks Kenichi - more comments inline. It would be great to hear some other opinions too. > > > On 14/06/2017 10:09, Ogaki, Kenichi wrote: >> Hi David, >> >> Thanks for you comments. >> See more comments inline, please. >> >> Thanks, >> Kenichi >> >> -----Original Message----- >> From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball >> Sent: Monday, June 12, 2017 11:39 PM >> To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org >> Subject: Re: [L3sm] Next Step of RFC8049 >> >> Thanks Kenichi, please see further thoughs inline: >> >> >> >> On 08/06/2017 05:01, Ogaki, Kenichi wrote: >> >> >> 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:l3sm-bounces@ietf.org] On Behalf Of David Ball >> Sent: Saturday, June 03, 2017 12:08 AM >> To: Qin Wu; l3sm@ietf.org >> 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. >> >> >> [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. >> >> >> >> 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. >> >> >> [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. > [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? > > [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. [DB3] Ok, thanks - that is what I thought, but it could be described more clearly in the RFC I think. >> 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. >> >> >> [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. > [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? > > [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). [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. >> 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. >> >> >> [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] > 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? > >> 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. >> >> >> [DB] So is there a reason it was not done that way? >> >> [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? > > [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. [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*? >> 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. >> >> [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). > >> >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [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. [DB3] Right - so this could use some more explanation in the text I think. > >> 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. >> >> >> [DB]: Ok, yes I can see how implementing that might not be straightforward. >> >> >> >> 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. >> >> >> [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. > [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. [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? >> 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. >> >> >> [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. > [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. > > [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... [DB3] Ah, yes I guess you could do it that way. >> 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. >> >> >> [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. > [DB2] My question was specifically about when the end-to-end leaf is set > to true. > > [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... >> 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? >> >> >> [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] 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". > > [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 >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [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. > [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. > >> 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. >> >> >> [DB] I think it would be useful to clarify it. Qin? >> >> >> >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [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. > [DB2] Ok. > >> 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. >> >> >> [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. > [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? > >> 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. >> >> >> [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. > [DB2] Ok. Qin, should we add this? > >> 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. >> >> >> [DB] Ok. >> >> >> >> 4. For IPv6 connection, is there a case where only link-local addresses are used? >> >> [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? >> >> [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 > >> 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. >> >> >> [DB] Qin, will you fix this? >> >> >> >> 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. >> >> >> [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 >> >> >> >> >> >> >> >> 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 >> L3sm@ietf.org >> https://www.ietf.org/mailman/listinfo/l3sm >> >> >> >> -- David Ball From nobody Thu Jun 22 05:45:59 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0548129404 for ; Thu, 22 Jun 2017 05:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LibsgCQHA8RG for ; Thu, 22 Jun 2017 05:45:55 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896B11292AE for ; Thu, 22 Jun 2017 05:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10784; q=dns/txt; s=iport; t=1498135554; x=1499345154; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=Y3iog8YEk77S4T8pc9rvUTCoXMle5Lt8PzHsOnLLL7g=; b=UqVXa3yx8vTzBzYfl8VEXEFtMKUxwloGc7Vtz7MbjNcW1RhB/IUNEz9h uUJwQTQfOi/NMiX8Iryu5WbbvrVL5VPYiGYFwJQdylUXhR49ptDIkpuZc LHsPPFDbYF7Brx/acAS8ggHu1aDYXqACIReHlLUV4zi/G9SEHjxqHcRy+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQDOuktZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhDqBDYNsihlzkEsiiCyIIoUqghEnhTNKAoM8GAECAQEBAQEBAWsdC4U?= =?us-ascii?q?YAQMBAiNDCxgcAwECFwEBDAYCAiEsAggGDQYCAQGKEAMVEKtsgiYqgyqDXw2EJ?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEaBYMng0yCCwuCboJXIIITDBwBBYJFgmEFlx2?= =?us-ascii?q?HCzuHM4ZsXIRnggmJE4ZziSWCOm2ISh84gQowIQgbFR+CfIQ/PjYBhx8NF4IZA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.39,373,1493683200"; d="scan'208,217";a="653786883" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2017 12:45:52 +0000 Received: from [10.55.221.38] (ams-bclaise-nitro5.cisco.com [10.55.221.38]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v5MCjq4V028678 for ; Thu, 22 Jun 2017 12:45:52 GMT References: <149382509814.21435.13312408514705930156.idtracker@ietfa.amsl.com> To: "l3sm@ietf.org" From: Benoit Claise X-Forwarded-Message-Id: <149382509814.21435.13312408514705930156.idtracker@ietfa.amsl.com> Message-ID: <8e4d5b55-7641-b024-4737-14c48de20b7d@cisco.com> Date: Thu, 22 Jun 2017 14:45:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <149382509814.21435.13312408514705930156.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------A0273E9BBEEAA8CAB0FE20A5" Content-Language: en-US Archived-At: Subject: [L3sm] Fwd: New Liaison Statement, "Liaison to IETF on IP Services Approved Draft 1" X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 12:45:58 -0000 This is a multi-part message in MIME format. --------------A0273E9BBEEAA8CAB0FE20A5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit FYI. Regards,B. -------- Forwarded Message -------- Subject: New Liaison Statement, "Liaison to IETF on IP Services Approved Draft 1" Date: Wed, 3 May 2017 08:24:58 -0700 From: Liaison Statement Management Tool To: Benoit Claise , Alvaro Retana , Alia Atlas , Deborah Brungard , Warren Kumari CC: Alvaro Retana , Deborah Brungard , nan@mef.net, Alia Atlas , Warren Kumari , The IETF Chair , ssteiff@pccwglobal.com, rraghu@ciena.com, Benoit Claise , Raghu Ranganathan Title: Liaison to IETF on IP Services Approved Draft 1 Submission Date: 2017-05-03 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1521/ From: Raghu Ranganathan To: Warren Kumari ,Benoit Claise ,Alia Atlas ,Alvaro Retana ,Deborah Brungard Cc: Alvaro Retana ,Deborah Brungard ,Alia Atlas ,Warren Kumari ,The IETF Chair ,Benoit Claise ,Raghu Ranganathan Response Contacts: rraghu@ciena.com, nan@mef.net, ssteiff@pccwglobal.com Technical Contacts: Purpose: For information Body: Following our previous liaisons, we would like to update you on the progress of the MEF IP Service Attributes project. A new Approved Draft of our specification for IP Service Attributes for Subscriber Services is available, which can be accessed as described below. Note that a corresponding specification for IP Service Attributes for Operator Services is in progress but an Approved Draft is not yet available. In the course of our work, we have reviewed some of the internet drafts from the L3SM working group that preceded publication of RFC 8049 ("Yang Data Model for L3VPN Service Delivery"), and we used this as input to our specification. Now that RFC 8049 is published, we intend to review it again to ensure our work remains aligned. We would appreciate your review of our Approved Draft, and in particular any assistance you can give in identifying areas where it may conflict or be otherwise misaligned with RFC 8049. Note that the scope of the current IP Service Attributes project does not include definition of a yang module; however, we expect that a future project will include specification of a yang module based on the service attributes defined in this document. It is our hope that such a module can be defined as an augment of the module defined in RFC 8049. MEF’s liaison partners may access all MEF approved drafts as follows: https://mef.net/liaison-login Username: mef Password: M3F3030 The next MEF meetings are: July 24 - 27, Toronto, Canada October 23 - 26, Raleigh, USA Attachments: L00263_001_LiaisontoIETFonIPServicesApprovedDraft1_Ball_Ranganathan.pdf https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-05-03-mef-ops-rtg-liaison-to-ietf-on-ip-services-approved-draft-1-attachment-1.pdf . --------------A0273E9BBEEAA8CAB0FE20A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit FYI.

Regards,B.


-------- Forwarded Message --------
Subject: New Liaison Statement, "Liaison to IETF on IP Services Approved Draft 1"
Date: Wed, 3 May 2017 08:24:58 -0700
From: Liaison Statement Management Tool <lsmt@ietf.org>
To: Benoit Claise <bclaise@cisco.com>, Alvaro Retana <aretana@cisco.com>, Alia Atlas <akatlas@gmail.com>, Deborah Brungard <db3546@att.com>, Warren Kumari <warren@kumari.net>
CC: Alvaro Retana <aretana@cisco.com>, Deborah Brungard <db3546@att.com>, nan@mef.net, Alia Atlas <akatlas@gmail.com>, Warren Kumari <warren@kumari.net>, The IETF Chair <chair@ietf.org>, ssteiff@pccwglobal.com, rraghu@ciena.com, Benoit Claise <bclaise@cisco.com>, Raghu Ranganathan <rraghu@ciena.com> 


Title: Liaison to IETF on IP Services Approved Draft 1
Submission Date: 2017-05-03
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1521/

From: Raghu Ranganathan <rraghu@ciena.com>
To: Warren Kumari <warren@kumari.net>,Benoit Claise <bclaise@cisco.com>,Alia Atlas <akatlas@gmail.com>,Alvaro Retana <aretana@cisco.com>,Deborah Brungard <db3546@att.com>
Cc: Alvaro Retana <aretana@cisco.com>,Deborah Brungard <db3546@att.com>,Alia Atlas <akatlas@gmail.com>,Warren Kumari <warren@kumari.net>,The IETF Chair <chair@ietf.org>,Benoit Claise <bclaise@cisco.com>,Raghu Ranganathan <rraghu@ciena.com>
Response Contacts: rraghu@ciena.com, nan@mef.net, ssteiff@pccwglobal.com
Technical Contacts: 
Purpose: For information

Body: Following our previous liaisons, we would like to update you on the progress of the MEF IP Service Attributes project. A new Approved Draft of our specification for IP Service Attributes for Subscriber Services is available, which can be accessed as described below. Note that a corresponding specification for IP Service Attributes for Operator Services is in progress but an Approved Draft is not yet available.

In the course of our work, we have reviewed some of the internet drafts from the L3SM working group that preceded publication of RFC 8049 ("Yang Data Model for L3VPN Service Delivery"), and we used this as input to our specification. Now that RFC 8049 is published, we intend to review it again to ensure our work remains aligned. We would appreciate your review of our Approved Draft, and in particular any assistance you can give in identifying areas where it may conflict or be otherwise misaligned with RFC 8049.

Note that the scope of the current IP Service Attributes project does not include definition of a yang module; however, we expect that a future project will include specification of a yang module based on the service attributes defined in this document. It is our hope that such a module can be defined as an augment of the module defined in RFC 8049.

MEF’s liaison partners may access all MEF approved drafts as follows:
https://mef.net/liaison-login
Username: mef 
Password: M3F3030

The next MEF meetings are:
July 24 - 27, Toronto, Canada 
October 23 - 26, Raleigh, USA
Attachments:

    L00263_001_LiaisontoIETFonIPServicesApprovedDraft1_Ball_Ranganathan.pdf
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-05-03-mef-ops-rtg-liaison-to-ietf-on-ip-services-approved-draft-1-attachment-1.pdf

.
--------------A0273E9BBEEAA8CAB0FE20A5-- From nobody Sat Jun 24 02:19:07 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB601294C8 for ; Sat, 24 Jun 2017 02:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swT0uhM5uW3S for ; Sat, 24 Jun 2017 02:19:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C774F1242F5 for ; Sat, 24 Jun 2017 02:19:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPT08463; Sat, 24 Jun 2017 09:18:59 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 24 Jun 2017 10:18:58 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Sat, 24 Jun 2017 17:18:52 +0800 From: Qin Wu To: David Ball , "stephane.litkowski@orange.com" , "Ogaki, Kenichi (ke-oogaki@kddi.com)" , "l3sm@ietf.org" Thread-Topic: [L3sm] Next Step of RFC8049 Thread-Index: AdLIzCXxBcQvJgePTDyhRzLdDi5cBQSos+gAARZ7BwAA32+/gABZEcKAAT9R1QAAIlktAAA3gU2AAF1OwTA= Date: Sat, 24 Jun 2017 09:18:52 +0000 Message-ID: References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> In-Reply-To: <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.594E2E84.0053, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 09cd5f5c66d70c8f50c2790042f914ea Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 09:19:06 -0000 U29ycnkgdG8gY2hpbWUgaW4sIGEgZmV3IGNvbW1lbnRzIGxpbmUgKG1hcmtlZCB3aXRoIFtRaW5d KS4NCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIERhdmlkIEJhbGwNCreiy83KsbzkOiAyMDE3xOo21MIyMsjVIDIwOjI2 DQrK1bz+yMs6IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBPZ2FraSwgS2VuaWNoaTsg UWluIFd1OyBsM3NtQGlldGYub3JnDQrW98ziOiBSZTogW0wzc21dIE5leHQgU3RlcCBvZiBSRkM4 MDQ5DQoNClRoYW5rcyBTdGVwaGFuZSAtIHJlc3BvbnNlcyBpbiBsaW5lIChtYXJrZWQgW0RCM10p Og0KDQpPbiAyMS8wNi8yMDE3IDEwOjU2LCBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSB3 cm90ZToNCj4gSGksDQo+DQo+IFBsZWFzZSBmaW5kIHNvbWUgY29tbWVudHMgaW5saW5lIChtYXJr ZWQgd2l0aCBbU0xJXSkNCj4NCj4NCj4+IAkzLglTb21ld2hhdCByZWxhdGVkLCBJIGFtIHRyeWlu ZyB0byB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYSBzaXRlIHdpdGggc3ViLVZQ TnMgKGkuZS4gZWFjaCBzaXRlLWFjY2Vzcy1saW5rIGlzIGNvbm5lY3RlZCB0byBhIGRpZmZlcmVu dCBWUE4pIHZzIHRyZWF0aW5nIGl0IGFzIHR3byBzaXRlcywgZWFjaCB3aXRoIGEgc2luZ2xlIHNp dGUtYWNjZXNzLWxpbmsuICBUaGUgdGV4dCBzYXlzIGEgc3ViLVZQTiAiaXMgc2ltaWxhciB0byBo YXZpbmcgc2VwYXJhdGUgc2l0ZXMsIGJ1dCBpbiB0aGlzIGNhc2UgdGhlIGN1c3RvbWVyIHdhbnRz IHRvIHNoYXJlIHNvbWUgcGh5c2ljYWwgY29tcG9uZW50cyB3aGlsZSBtYWludGFpbmluZyBzdHJv bmcgY29tbXVuaWNhdGlvbiBpc29sYXRpb24iLiAgRG9lcyAidGhpcyBjYXNlIiBtZWFuIHRoZSBz dWItVlBOIGNhc2Ugb3IgdGhlIG11bHRpcGxlIHNpdGVzIGNhc2U/ICBFaXRoZXIgd2F5LCB0aGUg Y3VzdG9tZXIgY291bGQgc2hhcmUgcGh5c2ljYWwgY29tcG9uZW50cyBhbmQgbWFpbnRhaW4gc3Ry b25nIGlzb2xhdGlvbiwgcmlnaHQ/DQo+PiAJDQo+PiAJCVtLT10gVGhpcyBjYXNlIG1lYW5zIHRo ZSBzdWItVlBOIGNhc2UsIGFuZCB5b3VyIGluZGljYXRpb24gaXMgcmlnaHQuDQo+Pg0KPj4NCj4+ IFtEQl0uICBPayAtIGlmIGl0IHRoZSBzYW1lIGFzIHVzaW5nIG11bHRpcGxlIHNpdGVzICh3aGlj aCB3b3VsZCBzdGlsbCBiZSB0b3BvbG9naWNhbGx5IHNlcGFyYXRlIGV2ZW4gaWYgdGhleSB1c2Ug dGhlIHNhbWUgcGh5c2ljYWwgY29tcG9uZW50cyksIEkgZ3Vlc3MgSSBkb24ndCB1bmRlcnN0YW5k IHRoZSBwdXJwb3NlIG9mIGhhdmluZyBzdWItVlBOIGFzIGFuIG9wdGlvbiAtIGJ1dCBnb29kIHRv IGtub3cgdGhlcmUgaXMgbm90aGluZyBleHRyYSBJJ20gbWlzc2luZyBoZXJlLg0KPj4NCj4+IFtL T10gU3ViLVZQTiBpcyBhIHJlYWwtbGlmZSB1c2VjYXNlIHByb3ZpZGVkIGluIGNvbW1lcmNpYWwg VlBOIHNlcnZpY2VzLg0KPiBbREIyXQ0KPiBTdXJlLCBJIGFtIG5vdCBkaXNwdXRpbmcgdGhhdCB0 aGlzIHNldC11cCBleGlzdHM7IG15IHF1ZXN0aW9uIGlzIHdoeSANCj4gaXQgc2hvdWxkIGJlIG1v ZGVsbGVkIGFzIGEgc3ViLVZQTiBpbnN0ZWFkIG9mIG1vZGVsbGluZyBhdCBzZXBhcmF0ZSBzaXRl cz8NCj4gVGhlIHNhbWUgc2NlbmFyaW8gY2FuIGJlIGV4cHJlc3NlZCBlaXRoZXIgd2F5LCByaWdo dD8NCj4NCj4gW1NMSV0gV2UgaGFkIHRoaXMgZGViYXRlIGVhcmxpZXIgd2hlbiBtb2RlbGluZyB0 aGUgc3ViVlBOICh1c2luZyBtdWx0aXBsZSBzaXRlcyB3YXMgb25lIG9mIHRoZSBwb3NzaWJpbGl0 eSBidXQgbm90IHJldGFpbmVkKS4NCj4gVGhlIHN1YlZQTnMgaGFzIHRoZSBwYXJ0aWN1bGFyaXR5 IG9mIHNoYXJpbmcgYSBjb21tb24gYmVhcmVyIGFuZCBhIGNvbW1vbiBDUEUgKGl0J3MgYSBWUkYg bGl0ZSBDUEUgaW4gdGVybSBvZiBjb25maWd1cmF0aW9uKS4NCg0KW0RCM10NCkkgYWdyZWUgdGhh dCB0d28gc2l0ZSBuZXR3b3JrIGFjY2Vzc2VzIGluIHRoZSBzYW1lIHNpdGUgYW5kIHVzaW5nIGEg c3ViVlBOIGNhbiBzaGFyZSBhIGNvbW1vbiBiZWFyZXIgYW5kIGEgY29tbW9uIENQRSwgYnV0IHR3 byBzaXRlLW5ldHdvcmstYWNjZXNzZXMgaW4gZGlmZmVyZW50IHNpdGVzIGNvdWxkIGFsc28gc2hh cmUgYSBjb21tb24gYmVhcmVyIGFuZCBhIGNvbW1vbiBDUEUsIHJpZ2h0PyAgUGVyIHlvdXIgYW5z d2VyIGFib3ZlLCB0aGUgc2l0ZSBpcyBhIG5vdGlvbiBkZWZpbmVkIGJ5IHRoZSBjdXN0b21lciwg c28gY291bGRuJ3QgdGhleSBkZXNpZ25hdGUgdHdvIHNpdGUgbmV0d29yayBhY2Nlc3NlcyBhcyBi ZWluZyBpbiBkaWZmZXJlbnQgc2l0ZXMgZXZlbiBpZiB0aGV5IHNoYXJlIHRoZSBzYW1lIGJlYXJl cj8NCg0KSSB1bmRlcnN0YW5kIHdoYXQgc3ViVlBOICpjYW4qIGRvIC0gd2hhdCBJJ20gdHJ5aW5n IHRvIHVuZGVyc3RhbmQgaXMgd2hldGhlciB0aGVyZSBpcyBhbnl0aGluZyB0aGF0ICpjYW4ndCog YmUgZG9uZSB3aXRoIG11bHRpcGxlIHNpdGVzLiBUaGUgdGV4dCBzdWdnZXN0cyB0aGF0IHRoZXJl IGlzIHNvbWUgZnVuY3Rpb25hbCBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgdHdvIGFwcHJvYWNo ZXMsIGJ1dCBpZiBzbywgSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgaXQgaXMuICBJdCB3b3VsZCBi ZSBoZWxwZnVsIHRvIGVpdGhlciBtYWtlIHRoZSB0ZXh0IGNsZWFyZXIgYWJvdXQgdGhlIGRpZmZl cmVuY2UsIG9yIGVsc2UgY2hhbmdlIGl0IHRvIHNheSB0aGF0IHRoZSB0d28gYXBwcm9hY2hlcyBh cmUgZnVuY3Rpb25hbGx5IHRoZSBzYW1lLg0KDQpbUWluXTogSG93IGRvZXMgdHdvIHNpdGUtbmV0 d29yay1hY2Nlc3MgYmVsb25naW5nIHRvIHR3byBkaWZmZXJlbnQgc2l0ZSBzaGFyZSB0aGUgc2Ft ZSBiZWFyZXIgb3IgcGh5c2ljYWwgY29tcG9uZW50Pw0KDQo+DQo+PiAJNS4JRm9yIGNsb3VkIGFj Y2VzcywgYSBzaW5nbGUgVlBOIGNhbiBjb25uZWN0IHRvIG11bHRpcGxlIGNsb3VkIHNlcnZpY2Vz LCBhbmQgZm9yIGVhY2ggY2xvdWQgc2VydmljZSB5b3UgaGF2ZSB0byBzcGVjaWZ5IHdoaWNoIHNp dGVzIGFyZSBhdXRob3JpemVkIHRvIGFjY2VzcyB0aGUgY2xvdWQuICBJcyB0aGVyZSBhIHJlYXNv biBpdCB3YXMgbW9kZWxsZWQgdGhpcyB3YXksIHJhdGhlciB0aGFuIGhhdmluZyBhIHNlcGFyYXRl IFZQTiBzZXJ2aWNlIHRvIGNvbm5lY3QgdG8gZWFjaCBjbG91ZCBzZXJ2aWNlPyAgSWYgdGhlcmUg d2FzIGEgc2VwYXJhdGUgVlBOIHNlcnZpY2UgZm9yIGVhY2ggY2xvdWQgc2VydmljZSwgdGhlbiBv bmx5IHRoZSByaWdodCBzaXRlcyB3b3VsZCBiZSBhdHRhY2hlZCB0byB0aGUgVlBOIGZvciBlYWNo IGNsb3VkLCBhbmQgaXQgd291bGQgbm90IGJlIG5lY2Vzc2FyeSB0byBoYXZlIGEgc2VwYXJhdGUg bGlzdCBvZiBhdXRob3JpemVkIHNpdGVzLCByaWdodD8NCj4+IAkJDQo+PiAJW0tPXSBUaGF0J3Mg cmlnaHQuDQo+Pg0KPj4NCj4+IFtEQl0gU28gaXMgdGhlcmUgYSByZWFzb24gaXQgd2FzIG5vdCBk b25lIHRoYXQgd2F5Pw0KPj4NCj4+IFtLT10gVGhlIHJlcXVpcmVtZW50IHRoYXQgYSBWUE4gd2Fu dCB0byBjb25uZWN0IG11bHRpcGxlIGNsb3VkcyBzdGlsbCBleGlzdHMuIFRoZSBsYXR0ZXIgY2Fz ZSBjYW5ub3QgY292ZXIgdGhpcy4NCj4gW0RCMl0NCj4gQ2FuIHlvdSBnaXZlIGFuIGV4YW1wbGUg dGhhdCBjYW4gYmUgbW9kZWxsZWQgd2l0aCBtdWx0aXBsZSBjbG91ZHMgaW4gYSANCj4gc2luZ2xl IFZQTiB0aGF0IGNvdWxkIG5vdCBiZSBtb2RlbGxlZCBhcyBtdWx0aXBsZSBWUE5zPw0KPg0KPiBb U0xJXSBVc2luZyBtdWx0aXBsZSBWUE5zIGhhcyBhIG1ham9yIGltcGFjdCBvbiB0aGUgc2Vydmlj ZSBkZXNpZ24gKG5vdCB0YWxraW5nIGFib3V0IGltcGxlbWVudGF0aW9uKS4gRnJvbSBhIHNlcnZp Y2UgcGVyc3BlY3RpdmUsIGxldCdzIHNheSB0aGF0IHRoZSBjdXN0b21lciBzdGFydHMgd2l0aCBh biBhbnkgdG8gYW55IFZQTiB3aGVyZSBhbGwgc2l0ZXMgY2FuIGNvbW11bmljYXRlIHdpdGggZWFj aCBvdGhlci4NCj4gQWZ0ZXIgc29tZSBtb250aHMsIGl0IHJlcXVpcmVzIGEgY2xvdWQgaW50ZXJj b25uZWN0aW9uLCBzbyBpdCdzIGh1YiBzaXRlIGNhbiBzcGF3biBWTSBpbiBBV1MgZm9yIGV4YW1w bGUgYnV0IHRoZSBvdGhlciBzaXRlcyBzaG91bGQgbm90IGFjY2VzcyB0byBBV1MuIEZyb20gYSBz ZXJ2aWNlIHBlcnNwZWN0aXZlLCB5b3UgbmVlZCB0byBtb2RlbCBpdCBhcyBhIGxpc3Qgb2YgYXV0 aG9yaXplZC91bmF1dGhvcml6ZWQgc2l0ZXMuDQo+IE5vdyBpbiB0ZXJtIG9mIGltcGxlbWVudGF0 aW9uLCB5b3UgY2FuIGRvIHdoYXQgeW91IHdhbnQsIHlvdSBjYW4gY3JlYXRlIGFkZGl0aW9uYWwg VlBOcywgeW91IGNhbiB1c2UgQUNMcyBvciB3aGF0ZXZlci4uLiBidXQgZnJvbSBhIHNlcnZpY2Ug cGVyc3BlY3RpdmUsIHRoZSBjdXN0b21lciBoYXMgYSBzaW5nbGUgVlBOIGFuZCBhIGNsb3VkIGFj Y2VzcyB3aXRoIGxpbWl0ZWQgYWNjZXNzLg0KDQpbREIzXQ0KT2sgLSBidXQgaW4gdGhpcyBzY2Vu YXJpbywgd2h5IHdvdWxkbid0IHRoZSBjdXN0b21lciBqdXN0IGdldCBhIG5ldyBzZXJ2aWNlIGNv bm5lY3RpbmcgdGhlIGh1YiBzaXRlIHRvIHRoZSBjbG91ZCB3aGVuIHRoZXkgbmVlZCBpdD8NCkkg Y2FuIHNlZSB3aHkgaXQgbWlnaHQgYmUgdHJlYXRlZCwgY29tbWVyY2lhbGx5LCBhcyBwYXJ0IG9m IHRoZSBzYW1lICpwcm9kdWN0KiwgYnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgaXQgd291bGQg bmVlZCB0byBiZSB0aGUgc2FtZSAqc2VydmljZSo/DQoNCltRaW5dOlRoaXMgcHJvdmlkZXMgZmlu ZSBncmFudWxhcml0eSBjb250cm9sIG9uIGEgc2l0ZSBnZXR0aW5nIGFjY2VzcyB0byBwdWJsaWMg Y2xvdWQgb3IgaW50ZXJuZXQuDQpZb3UgbWF5IGFsc28gYWRkIGEgbmV3IHNpdGUgdG8gYW4gZXhp c3RpbmcgVlBOLCBidXQgdGhpcyBzaXRlIG1heSBub3QgaGF2ZSBhdXRob3JpemF0aW9uIHRvIGdl dCBhY2Nlc3MgdG8gcHVibGljIGNsb3VkIHVubGVzcyB5b3UgZXhwbGljaXRseSBjb25maWd1cmUg aXQuDQoNCj4+DQo+PiAJOC4JVGhlcmUgaXMgYSAnc3ZjLW10dScgbGVhZiB1bmRlciB0aGUgc2l0 ZS1uZXR3b3JrLWFjY2VzczsgaG93ZXZlciwgaXQncyBub3QgbWVudGlvbmVkIGluIHNlY3Rpb24g NiBhbmQgaXQncyBub3QgY2xlYXIgaG93IGl0J3MgaW50ZW5kZWQgdG8gYmUgdXNlZC4gIEF0IGxl YXN0IGZvciBJUHY0LCBwYWNrZXRzIGxhcmdlciB0aGFuIHRoZSBNVFUgY2FuIGJlIGZyYWdtZW50 ZWQgKGFsdGhvdWdoIHRoYXQgbWlnaHQgYmUgdW5kZXNpcmFibGUsIHNvIGl0IG1pZ2h0IGJlIHVz ZWZ1bCB0byBoYXZlIGEgcGVyLVZQTiBrbm9iIHRvIGRpc2FibGUgaXQpLiAgSSB0aGluayB0aGUg bWluaW11bSByZXF1aXJlbWVudCBpcyB0aGF0IHRoZSBjdXN0b21lciBhbmQgdGhlIFNQIGFncmVl IG9uIHRoZSBsb3dlc3QgTVRVIGFjcm9zcyB0aGUgd2hvbGUgVlBOLCBzbyB0aGF0IHRoZSBjdXN0 b21lciBjYW4gYmUgY2VydGFpbiB0aGF0IHBhY2tldHMgc2hvcnRlciB0aGFuIHRoYXQgd2lsbCBi ZSBkZWxpdmVyZWQuICBPZiBjb3Vyc2UsIHRoZSBjdXN0b21lciBtaWdodCB1c2UgdGVjaG5pcXVl cyBsaWtlIHBhdGggTVRVIGRpc2NvdmVyeSB0byBkZXRlcm1pbmUgdGhhdCB0aGV5IGNhbiB1c2Ug YSBsYXJnZXIgTVRVIGZvciBwYXJ0aWN1bGFyIHBhdGhzLiAgSSB0aGluayBpdCB3b3VsZCBiZSB1 c2VmdWwgdG8gaGF2ZSBzb21lIGRpc2N1c3Npb24gb2YgdGhpcyB0b3BpYyBpbiB0aGUgUkZDLg0K Pj4gCQ0KPj4gCVtLT10gVGhpcyBsZWFmIGlzIHJlcXVpcmVkIHRvIGJlIHNldCB0aGUgdmFsdWUg aWYgYSBjdXN0b21lciByZXF1aXJlcyB0byBkbyBzby4gQnV0LCBJIGhhdmUgbm8gaWRlYSBhYm91 dCB0aGUgY2FzZS4NCj4+DQo+Pg0KPj4gW0RCXSBBbnlvbmUgZWxzZT8gIEl0IGRvZXNuJ3Qgc2Vl bSB1c2VmdWwgdG8gaGF2ZSBhIGxlYWYgaW4gdGhlIG1vZGVsIGlmIHdlIGRvbid0IGtub3cgd2hh dCBpdCBtZWFucy4uLg0KPj4NCj4+DQo+IFtTTEldIFRoaXMgd2FzIG1haW5seSBpbnRyb2R1Y2Vk IGZvciB0d28gdXNlIGNhc2VzOg0KPiAtIGN1c3RvbWVyIHJlcXVpcmluZyBhIHNwZWNpZmljIElQ djQgb3IgSVB2NiBNVFUgKGp1bWJvIE1UVSkNCj4gLSBjYXJyaWVyJ3MgY2FycmllciBjYXNlIHdo ZXJlIHRoZSBjb25uZWN0aW9uIGlzIGFuIE1QTFMgY29ubmVjdGlvbiBhbmQgbm90IG1vcmUgSVAs IHNvIHdlIG5lZWQgdG8ga25vdyB3aGF0IGlzIGV4cGVjdGVkIGluIHRlcm0gb2YgIm1wbHMgbXR1 Ig0KPiBGb3Igc3VyZSB0aGUgY3VzdG9tZXIgbmVlZHMgdG8gZmlsbCBjb25zaXN0ZW50IGluZm9y bWF0aW9ucyBpbiBvcmRlciB0byBtYWtlIGl0IHdvcmtpbmcuDQoNCltEQjNdDQpSaWdodCAtIHNv IHRoaXMgY291bGQgdXNlIHNvbWUgbW9yZSBleHBsYW5hdGlvbiBpbiB0aGUgdGV4dCBJIHRoaW5r Lg0KDQpbUWluXTogU3VyZS4NCj4NCj4+IAk5LglUaGVyZSBpcyBhIHBlci1zaXRlIGxpbWl0IG9u IHRoZSBudW1iZXIgb2YgIElQdjQvSVB2NiByb3V0ZXMgKCJtYXhpbXVtLXJvdXRlcyIpIC0gaXMg dGhpcyB0aGUgbWF4aW11bSBudW1iZXIgb2Ygcm91dGVzIHRoYXQgY2FuIGJlIGFkdmVydGlzZWQg YnkgdGhlIGN1c3RvbWVyIHRvd2FyZHMgdGhlIFNQIGF0IHRoYXQgc2l0ZT8gIEluIGEgbXVsdGkt VlBOIGNhc2UsIHdvdWxkIGl0IGJlIHVzZWZ1bCB0byBoYXZlIGEgcGVyLXNpdGUsIHBlci1WUE4g bGltaXQsIGUuZy4gaW4gdGhlIGNhc2Ugd2hlcmUgb25lIG9mIHRoZSBWUE5zIGlzIGFuIGV4dHJh bmV0LCB0byBsaW1pdCB0aGUgbnVtYmVyIG9mIHByZWZpeGVzIHRoYXQgY2FuIGJlIGFkdmVydGlz ZWQgaW50byB0aGUgZXh0cmFuZXQgYXQgdGhhdCBzaXRlPw0KPj4gCQkNCj4+IAlbS09dIEl0IG1h eSBiZSB1c2VmdWwsIGJ1dCBhIHNvbHV0aW9uIGlzIHJlcXVpcmVkLCBhbmQgSSBkb24ndCBrbm93 IHN1Y2ggYW4gZXhpc3Rpbmcgc29sdXRpb24uDQo+Pg0KPj4NCj4+IFtEQl06IE9rLCB5ZXMgSSBj YW4gc2VlIGhvdyBpbXBsZW1lbnRpbmcgdGhhdCBtaWdodCBub3QgYmUgc3RyYWlnaHRmb3J3YXJk Lg0KPj4NCj4+DQo+Pg0KPj4gCTEwLglUaGVyZSBpcyBhIHFvcy1jbGFzc2lmaWNhdGlvbi1wb2xp Y3kgKGVpdGhlciBwZXItc2l0ZSBvciBwZXItc2l0ZS1uZXR3b3JrLWFjY2VzcyksIHdoaWNoIGRl c2NyaWJlcyBob3cgdG8gbWFwIHBhY2tldHMgdG8gdGhlIHJpZ2h0IGNsYXNzIG9mIHNlcnZpY2Uu ICBJbiBhIHNpbmdsZS1WUE4gY2FzZSwgdGhpcyBpcyBmaW5lLCBidXQgSSBhbSBub3Qgc3VyZSBo b3cgdG8gaW50ZXJwcmV0IGl0IHdoZW4gdGhlIHNpdGUgaXMgYXR0YWNoZWQgdG8gbXVsdGlwbGUg VlBOcy4gIFRoZSBkaWZmZXJlbnQgVlBOcyBtaWdodCBoYXZlIGRpZmZlcmVudCBjbGFzc2VzIG9m IHNlcnZpY2UsIHNvIGRvZXNuJ3QgdGhlIGNsYXNzaWZpY2F0aW9uIHBvbGljeSBuZWVkIHRvIGJl IHBlci1zaXRlIHBlci1WUE4sIG5vdCBqdXN0IHBlci1zaXRlPw0KPj4gCQ0KPj4gCVtLT10gQXMg ZGVzY3JpYmVkIGluIDYuMTIuMi4xLCB3aGVyZSB0byBjbGFzc2lmeSBhbmQgYXBwbHkgdGhlIHFv cyBpcyB1cCB0byB0aGUgU1AsIGFuZCBvdXRzaWRlIG9mIHNjb3BlIG9mIHRoaXMgbW9kZWwuDQo+ Pg0KPj4NCj4+IFtEQl0gQWdyZWVkLCBidXQgdGhhdCB3YXNuJ3QgbXkgcXVlc3Rpb24uICBUaGUg cXVlc3Rpb24gaXMsIGluIGEgbXVsdGktVlBOIGNhc2UsIGRvbid0IHlvdSB3YW50IGEgZGlmZmVy ZW50IFFvUyBwb2xpY3kgZm9yIGVhY2ggVlBOIGF0IHRoZSBzaXRlPw0KPj4NCj4+IFtLT10gQXMg SSB3cm90ZSBiZWxvdywgd2UgbmVlZCBhdCBsZWFzdCBjbGFzc2lmeS9hcHBseSBhIHFvcyBhdCBp bnB1dC9vdXRwdXQgb2YgUEUsIG5vdCBkaWZmZXJlbnRpYXRlIGl0IHBlciBWUE4uIEJ1dCwgb3Ro ZXIgU1BzIG1heSB3YW50IHRoaXMuDQo+IFtEQjJdIFJpZ2h0IC0gc28gc2hvdWxkbid0IHRoZSBt b2RlbCBzdXBwb3J0IGl0Pw0KPiBbU0xJXSBJJ20gbm90IHN1cmUgdGhpcyBpcyBuZWNlc3Nhcnks IGluIHRoZSBtdWx0aVZQTiBjYXNlLCB0aGUgc2l0ZSBpcyAic2hhcmVkIiwgc28gdGhlIGN1c3Rv bWVyIGV4cGVjdHMgZmxvd3MgdG8gZ28gdG8gc2l0ZXMgdGhhdCBhcmUgbG9jYXRlZCBpbiBkaWZm ZXJlbnQgVlBOcy4gVGhlIGN1c3RvbWVyIGNhbiB1c2UgdGhlIGRzdC1wcmVmaXggb3IgdGhlIHRh cmdldC1zaXRlIGluIG9yZGVyIHRvIHNldCBhIHBhcnRpY3VsYXIgY2xhc3MgZm9yIGEgcGFydGlj dWxhciBmbG93IHdoYXRldmVyIHRoZSBWUE4uDQoNCltEQjNdDQpSaWdodCwgYnV0IGl0IHdvdWxk IGJlIHZlcnkgZWFzeSB3aXRoIHRoaXMgbWVjaGFuaXNtIGZvciB0aGUgY3VzdG9tZXIgdG8gbWFr ZSBhIG1pc3Rha2UgYW5kIGhhdmUgYSBwb2xpY3kgdGhhdCBtYXBzIGEgcGFja2V0IHRoYXQgd2ls bCBnbyB0byBhIHNpdGUgaW4gb25lIFZQTiB0byBhIGNsYXNzIHRoYXQgb25seSBleGlzdHMgaW4g dGhlIG90aGVyIFZQTjsgYW5kIG1vcmVvdmVyLCBpdCB3b3VsZCBiZSBoYXJkIGZvciB0aGUgU1Ag dG8gY2hlY2sgdGhpcy4gV291bGQgaXQgbm90IGJlIGJldHRlciB0byBkZXNpZ24gdGhlIG1vZGVs IHNvIHRoYXQgdGhlc2Ugc29ydHMgb2YgY29uc2lzdGVuY3kgY2hlY2tzIGFyZSBpbXBsaWNpdCBp biB0aGUgc3RydWN0dXJlIG9mIHRoZSBtb2RlbCwgcmF0aGVyIHRoYW4gcmVseWluZyBvbiB0aGUg Y3VzdG9tZXIgbm90IHRvIG1ha2UgYSBtaXN0YWtlPw0KDQpPZiBjb3Vyc2UsIGlmIGFsbCB0aGUg VlBOcyBoYXZlIHRoZSBzYW1lIHNldCBvZiBjbGFzc2VzLCB0aGVuIHRoZXJlIGlzIG5vIGlzc3Vl LiAgUGVyaGFwcyB0aGF0IGlzIHRoZSBjb21tb24gY2FzZT8NCg0KW1Fpbl06IEF0dGFjaGluZyBz aXRlIHRvIGFwcHJvcHJpYXRlIFZQTiBpcyByZWFsaXplZCB1c2luZyB2cG4tYXR0YWNobWVudCwg ZWl0aGVyIHJlZmVyZW5jaW5nIFZQTiBkaXJlY3RseSBvciByZWZlcmVuY2luZyB2cG4gcG9saWN5 LiBJbiB0aGF0IHdheSwgc2l0ZSB3aWxsIGtub3cgdG8gd2hpY2ggVlBOIHRoZSBwYWNrZXQgc2hv dWxkIGJlIGZvcndhcmRlZC4NCg0KPj4gCTEyLglPbiBzaW1pbGFyIGxpbmVzLCBpbiB0aGUgcW9z LXByb2ZpbGUgdGhlcmUgaXMgYSBndWFyYW50ZWVkLWJhbmR3aWR0aCwgd2hpY2ggY2FuIGVpdGhl ciBiZSBmb3IganVzdCB0aGUgYWNjZXNzLCBvciBjYW4gYmUgZW5kLXRvLWVuZC4gIEhvdyBzaG91 bGQgYW4gZW5kLXRvLWVuZCBiYW5kd2lkdGggZ3VhcmFudGVlIGJlIGludGVycHJldGVkIGlmIHRo ZSBWUE4gaGFzIG1vcmUgdGhhbiB0d28gc2l0ZXM/ICBPciBkb2VzIGl0IG9ubHkgbWFrZSBzZW5z ZSBmb3IgYSBQMlAgY2FzZT8NCj4+IAkJDQo+PiAJW0tPXSBTYW1lIGNvbW1lbnQgYXMgYWJvdmUu IEFzIEkga25vdywgYSBTUCBjb250cm9scyB0aGUgYmFuZHdpZHRoIGF0IGlucHV0L291dHB1dCBv ZiBQRS4NCj4+DQo+Pg0KPj4gW0RCXSBBZ3JlZWQgLSBidXQgYWdhaW4sIHRoZSBxdWVzdGlvbiBp cyBhYm91dCB0aGUgbWVhbmluZyBvZiB0aGUgYXR0cmlidXRlIHJhdGhlciB0aGFuIHdoZXJlIHRo ZSBTUCBpbXBsZW1lbnRzIGl0LiAgSW4gYSBWUE4gd2l0aCAxMCBzaXRlcywgd2hhdCBkb2VzIGl0 IG1lYW4gdG8gc2F5IHRoYXQgdGhlIGVuZC10by1lbmQgYmFuZHdpZHRoIGlzIDEwTWIvcz8NCj4+ DQo+PiBbS09dIEZvciBvdXIgY2FzZSwgdGhpcyBtZWFucyBub3QgYW4gZW5kLXRvLWVuZCBxb3Ms IGJ1dCBhbiBhY2Nlc3MgcW9zLiBJZiBhIFNQIHdhbnRzIGFuIGVuZC10by1lbmQgcW9zLCBoZS9z aGUgbXVzdCBuZWdvdGlhdGUgc29tZSBjb25zdHJhaW50cyBvciBjb25kaXRpb25zIHdpdGggaGVy L2hpcyBjdXN0b21lciBvdXRzaWRlIG9mIHRoaXMgbW9kZWwuDQo+IFtEQjJdIE15IHF1ZXN0aW9u IHdhcyBzcGVjaWZpY2FsbHkgYWJvdXQgd2hlbiB0aGUgZW5kLXRvLWVuZCBsZWFmIGlzIA0KPiBz ZXQgdG8gdHJ1ZS4NCj4NCj4gW1NMSV0gVGhlIG1haW4gdXNlIGNhc2UgaXMgUDJQLCBidXQgaWYg aXQgaXMgc2V0IGZvciBhIGNsYXNzIHdoaWNoIGludm9sdmVzIG1vcmUgdGhhbiB0d28gc2l0ZXMs IHRoZSByZXNlcnZhdGlvbiB3aWxsIGJlIGRvbmUgdG8gYWxsIHRoZSBzaXRlcyBpbnZvbHZlZC4N Cg0KW0RCM10NClNvLCBmb3IgZXhhbXBsZSwgc3VwcG9zZSBJIGhhdmUgYSBWUE4gd2l0aCA1IHNp dGVzLCB3aXRoIHRoZSBmb2xsb3dpbmcNCnNldHRpbmdzOg0KICAqIFNpdGUgQTogc3ZjLWlucHV0 LWJhbmR3aWR0aCA9IHN2Yy1vdXRwdXQtYmFuZHdpZHRoID0gMTAwMDAwMDAwLCBmb3IgY2xhc3Mg ImZvbyIgZ3VhcmFudGVlZC1idy1wZXJjZW50ID0gMTAsIGVuZC10by1lbmQgPSB0cnVlDQogICog U2l0ZSBCOiBzdmMtaW5wdXQtYmFuZHdpZHRoID0gc3ZjLW91dHB1dC1iYW5kd2lkdGggPSAyMDAw MDAwMDAsIGZvciBjbGFzcyAiZm9vIiBndWFyYW50ZWVkLWJ3LXBlcmNlbnQgPSAyMCwgZW5kLXRv LWVuZCA9IHRydWUNCiAgKiBTaXRlIEM6IHN2Yy1pbnB1dC1iYW5kd2lkdGggPSBzdmMtb3V0cHV0 LWJhbmR3aWR0aCA9IDMwMDAwMDAwMCwgZm9yIGNsYXNzICJmb28iIGd1YXJhbnRlZWQtYnctcGVy Y2VudCA9IDMwLCBlbmQtdG8tZW5kID0gdHJ1ZQ0KICAqIFNpdGUgRDogc3ZjLWlucHV0LWJhbmR3 aWR0aCA9IHN2Yy1vdXRwdXQtYmFuZHdpZHRoID0gNDAwMDAwMDAwLCBmb3IgY2xhc3MgImZvbyIg Z3VhcmFudGVlZC1idy1wZXJjZW50ID0gNDAsIGVuZC10by1lbmQgPSB0cnVlDQogICogU2l0ZSBF OiBzdmMtaW5wdXQtYmFuZHdpZHRoID0gc3ZjLW91dHB1dC1iYW5kd2lkdGggPSA1MDAwMDAwMDAs IGZvciBjbGFzcyAiZm9vIiBndWFyYW50ZWVkLWJ3LXBlcmNlbnQgPSA1MCwgZW5kLXRvLWVuZCA9 IHRydWUNCg0KV2hhdCBkb2VzIHRoaXMgbWVhbj8gIFdoYXQgYmFuZHdpZHRoIGlzIHJlc2VydmVk IGJldHdlZW4gZWFjaCBvZiB0aGUgMTAgcGFpcnMgb2Ygc2l0ZXM/DQoNCltRaW5dOiBzZXQgZW5k IHRvIGVuZCBsZWFmIGFzIHRydWUgbWVhbnMgYmFuZHdpZHRoIHJlc2VydmF0aW9uIGlzIGFwcGxp ZWQgdG8gZW5kIHRvIGVuZCBjb25uZWN0aXZpdHksIGFjcm9zcyBNUExTIHRyYW5zcG9ydCBuZXR3 b3JrLg0KU2V0IGVuZCB0byBlbmQgbGVhZiBhcyBmYWxzZSBtZWFucyBiYW5kd2lkdGggcmVzZXJ2 YXRpb24gaXMgb25seSBhcHBsaWVkIHRvIGFjY2VzcyBjb25uZWN0aXZpdHkgZm9yIGN1c3RvbWVy IHNpdGUuDQpDaG9vc2UgY2xhc3MgImZvbyIgd2l0aCBzcGVjaWZpYyB0YXJnZXQgc2l0ZSwgd2Ug a25vdyBmcm9tIHdoaWNoIHNpdGUgdG8gd2hpY2ggc2l0ZSBiYW5kd2lkdGggcmVzZXJ2YXRpb24g bmVlZHMgdG8gYmUgcGVyZm9ybWVkLg0KDQo+PiAJMTMuCUxvdHMgb2YgcXVlc3Rpb25zIGFib3V0 IHRoZSByb3V0aW5nLXByb3RvY29sczoNCj4+IAkNCj4+IAkJMS4JV2hlbiB0aGUgcm91dGluZyBw cm90b2NvbCBpcyAiZGlyZWN0IiwgdGhlIFNQIHJvdXRlcyB0cmFmZmljIHRvd2FyZHMgdGhlIHBy ZWZpeCBzcGVjaWZpZWQgYnkgdGhlIGNvbm5lY3Rpb24gYWRkcmVzczsgaG93ZXZlciwgb25lIHdv dWxkIGV4cGVjdCB0aGF0IHRoZXkgYWx3YXlzIGRvIHRoaXMgcmVnYXJkbGVzcyBvZiB3aGF0IG90 aGVyIHJvdXRpbmcgcHJvdG9jb2wgaXMgaW4gdXNlLCByaWdodD8gIFNvLCB3aGF0IGlzIHRoZSBk aWZmZXJlbmNlIGJldHdlZW4gc3BlY2lmeWluZyByb3V0aW5nIHByb3RvY29sICJkaXJlY3QiLCBh bmQgbGVhdmluZyB0aGUgcm91dGluZyBwcm90Y29sIGxpc3QgZW1wdHk/DQo+PiAJDQo+PiAJDQo+ PiAJW0tPXSBUaGUgbGlzdCByb3V0aW5nLXByb3RvY29sIGhhcyB0aGUgZW50aXR5IHdpdGggInR5 cGUiIGFzIHRoZSBrZXkuIFRoZW4gZW1wdHkgcm91dGluZyBwcm90b2NvbCBpcyBub3QgYWxsb3dl ZC4NCj4+DQo+Pg0KPj4gW0RCXSBJIG1lYW50IGFuIGVtcHR5IGxpc3QsIG5vdCBhbiBlbXB0eSBl bGVtZW50IGluIHRoZSBsaXN0LiAgVGhlcmUgaXMgbm8gIm1pbi1lbGVtZW50cyIgb24gdGhlIHJv dXRpbmctcHJvdG9jb2wgbGlzdCwgc28gdGhlIGxpc3QgaXRzZWxmIGNvdWxkIGJlIGVtcHR5Lg0K Pj4NCj4+IFtLT10gSSB1bmRlcnN0YW5kLiBJIHRoaW5rIGl0IHNob3VsZCBzcGVjaWZ5IHRoZSAi bWluLWVsZW1lbnRzIiB3aXRoIG9uZSBlbnRpdHkuIEJ1dCwgd2UgbWF5IGJlIGFibGUgdG8gdW5k ZXJzdGFuZCB0aGUgY2FzZSBhcyB0aGUgZGlyZWN0LCBpZiB0aGUgbGlzdCBpcyBlbXB0eS4NCj4g W0RCMl0gUmlnaHQgLSBzbyBpZiB0aGUgImRpcmVjdCIgY2FzZSBjYW4gYmUgcmVwcmVzZW50ZWQg YnkgYW4gZW1wdHkgDQo+IGxpc3QsIHRoZW4gdGhlcmUgaXMgbm8gbmVlZCB0byBleHBsaWNpdGx5 IHNwZWNpZnkgImRpcmVjdCIuDQo+DQo+IFtTTEldIFNvbWUgU1BzIHByZXZlbnRzIHRvIGFkdmVy dGlzZSB0aGUgaW50ZXJjbyBzdWJuZXQgZXhjZXB0IGlmIHRoZSBjdXN0b21lciByZWFsbHkgcmVx dWlyZXMgaXQuDQoNCltEQjNdDQpTb3JyeSBJIGRpZCBub3QgdW5kZXJzdGFuZCBob3cgdGhpcyBy ZWxhdGVzIHRvIHRoZSBpc3N1ZT8NCg0KW1Fpbl06IFdoeSBub3Qgc3BlY2lmeSBkaXJlY3Qgcm91 dGUgaW4gdGhlIG1vZGVsIGlmIGRpcmVjdCByb3V0ZSBuZWVkIHRvIGJlIHN1cHBvcnRlZD8gV2Ug Y291bGQgYWQgbWluLWVsZW1lbnQgIjEiIHRvIG1ha2Ugc3VyZSB0aGUgbGlzdCBjYW5ub3QgYmUg ZW1wdHkuDQo= From nobody Sun Jun 25 20:33:29 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EB4126FB3 for ; Sun, 25 Jun 2017 20:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LkolEa1Qq-j for ; Sun, 25 Jun 2017 20:33:24 -0700 (PDT) Received: from post-send.kddi.com (athena4.kddi.com [27.90.165.197]) by ietfa.amsl.com (Postfix) with ESMTP id A3B14126D46 for ; Sun, 25 Jun 2017 20:33:23 -0700 (PDT) Received: from LTMC2122.kddi.com (LTMC2122.kddi.com [10.206.0.63]) by post-send.kddi.com (KDDI Mail) with ESMTP id 242C6120043; Mon, 26 Jun 2017 12:33:22 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2122.kddi.com with ESMTP; Mon, 26 Jun 2017 12:33:22 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id E74754C005A; Mon, 26 Jun 2017 12:33:21 +0900 (JST) Received: from LTMC2154.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id DB2B74C0058; Mon, 26 Jun 2017 12:33:21 +0900 (JST) Received: from LTMC2154.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2154.kddi.com with ESMTP id v5Q3XLqK021224; Mon, 26 Jun 2017 12:33:21 +0900 Received: from LTMC2154.kddi.com.mid_7358094 (localhost.localdomain [127.0.0.1]) by LTMC2154.kddi.com with ESMTP id v5Q3NKHf013840; Mon, 26 Jun 2017 12:23:20 +0900 X-SA-MID: 7358094 Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Mon, 26 Jun 2017 12:23:19 +0900 From: "Ogaki, Kenichi" To: "'David Ball'" , , "'Qin Wu'" , References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> In-Reply-To: <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> Date: Mon, 26 Jun 2017 12:23:19 +0900 Message-ID: <00b101d2ee2b$8ef28ab0$acd7a010$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI8KJ/JrK2KyxsjaGJAhXNMm3Sl2gG6ddmrAczEpsMBsDkrZAKEX+92AgfRRr0BCjGOgwFvVOKzoQHvlcA= Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 03:33:28 -0000 Hi David, Qin, See comments inline[KO3], please. I also added Qin's comment to previous one. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball Sent: Thursday, June 22, 2017 9:26 PM To: stephane.litkowski@orange.com; Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org Subject: Re: [L3sm] Next Step of RFC8049 Thanks Stephane - responses in line (marked [DB3]): On 21/06/2017 10:56, stephane.litkowski@orange.com wrote: > Hi, > > Please find some comments inline (marked with [SLI]) > > > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Tuesday, June 20, 2017 19:33 > To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org > Subject: Re: [L3sm] Next Step of RFC8049 > > Thanks Kenichi - more comments inline. It would be great to hear some other opinions too. > > > On 14/06/2017 10:09, Ogaki, Kenichi wrote: >> Hi David, >> >> Thanks for you comments. >> See more comments inline, please. >> >> Thanks, >> Kenichi >> >> -----Original Message----- >> From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball >> Sent: Monday, June 12, 2017 11:39 PM >> To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org >> Subject: Re: [L3sm] Next Step of RFC8049 >> >> Thanks Kenichi, please see further thoughs inline: >> >> >> >> On 08/06/2017 05:01, Ogaki, Kenichi wrote: >> >> >> 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:l3sm-bounces@ietf.org] On Behalf Of David Ball >> Sent: Saturday, June 03, 2017 12:08 AM >> To: Qin Wu; l3sm@ietf.org >> 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. >> >> >> [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. >> >> >> >> 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. >> >> >> [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. > [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? > > [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. [DB3] Ok, thanks - that is what I thought, but it could be described more clearly in the RFC I think. >> 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. >> >> >> [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. > [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? > > [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). [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? [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. >> 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. >> >> >> [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] > 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. > >> 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. >> >> >> [DB] So is there a reason it was not done that way? >> >> [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? > > [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. [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. >> 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. >> >> [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). > >> >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [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. [DB3] Right - so this could use some more explanation in the text I think. [Qin]: Sure. > >> 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. >> >> >> [DB]: Ok, yes I can see how implementing that might not be straightforward. >> >> >> >> 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. >> >> >> [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. > [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. [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. [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. >> 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. >> >> >> [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. > [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. > > [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... [DB3] Ah, yes I guess you could do it that way. >> 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. >> >> >> [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. > [DB2] My question was specifically about when the end-to-end leaf is > set to true. > > [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... [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. >> 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? >> >> >> [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] 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". > > [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? [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. [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 >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [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. > [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. > >> 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. >> >> >> [DB] I think it would be useful to clarify it. Qin? >> >> >> >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [DB] Ok. >> >> >> >> 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. >> >> >> [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. > [DB2] Ok. > >> 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. >> >> >> [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. > [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? [KO3] I understand, but I'm not sure there is a specific rational for this case. > >> 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. >> >> >> [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. > [DB2] Ok. Qin, should we add this? > >> 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. >> >> >> [DB] Ok. >> >> >> >> 4. For IPv6 connection, is there a case where only link-local addresses are used? >> >> [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? >> >> [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 > >> 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. >> >> >> [DB] Qin, will you fix this? >> >> >> >> 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. >> >> >> [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 >> >> >> >> >> >> >> >> 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 >> L3sm@ietf.org >> https://www.ietf.org/mailman/listinfo/l3sm >> >> >> >> -- David Ball _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Tue Jun 27 04:42:02 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0962B129AC4 for ; Tue, 27 Jun 2017 04:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK4lIm7i1hKC for ; Tue, 27 Jun 2017 04:41:57 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6491B129789 for ; Tue, 27 Jun 2017 04:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13592; q=dns/txt; s=iport; t=1498563716; x=1499773316; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=xGYrLOHaOtm66+k6z16F21+c7pHulB/bbYC/QYgGNnM=; b=Wwyz8tLcJZ1aUkpkivGNoBnwMR71zAGAFVDROzMBpMKC7sdHpFg55Ymm cnV5WjrLt7HQWZ1bSIVAPD7Xd1a6jWvAyhIo5DxMvROtQvmCkM8kv4XqF Tp5/OHbSpvqr4zmsDKtOEzxs1Qz7OogUSjdGSLsK9YEA4PVTZRuuR+9C1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAQAMRFJZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyuCHoNsihlzkE8ic5UKghGGKQKDOBgBAgEBAQEBAQFrKIUYAQEBAQI?= =?us-ascii?q?BIxVRCw4KAgImAgJXBgEMBgIBARWKDwivfYImi14BAQEBAQEBAQIBAQEBAQEBA?= =?us-ascii?q?QEBAR2BC4Icg0yBYSsLgWJYNIE8gwpQgmeCYQEEnm+Kd4h0ix6GdoxViE8fOIE?= =?us-ascii?q?KMCEIGxVJhREFBxCBZz82hl2CPwEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,399,1493683200"; d="scan'208";a="695432516" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 11:41:53 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v5RBfrDK015509; Tue, 27 Jun 2017 11:41:53 GMT To: Qin Wu , "stephane.litkowski@orange.com" , "Ogaki, Kenichi (ke-oogaki@kddi.com)" , "l3sm@ietf.org" References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> From: David Ball Message-ID: <4f3c76b7-2e8d-4736-3107-9275e732c425@cisco.com> Date: Tue, 27 Jun 2017 12:41:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 11:42:00 -0000 Thanks Qin - more below tagged with [DB4]. On 24/06/2017 10:18, Qin Wu wrote: > >>> 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. >>> >>> >>> [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. >> [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? >> >> [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). > [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? [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". >>> 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. >>> >>> >>> [DB] So is there a reason it was not done that way? >>> >>> [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? >> >> [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. > [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. [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? >>> 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. >>> >>> >>> [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. >> [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. > [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. [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. >>> 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. >>> >>> >>> [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. >> [DB2] My question was specifically about when the end-to-end leaf is >> set to true. >> >> [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? > > [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. [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? >>> 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? >>> >>> >>> [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] 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". >> >> [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? > > [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 From nobody Tue Jun 27 04:53:19 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3E1129ADD for ; Tue, 27 Jun 2017 04:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZfhXRjOl7mJ for ; Tue, 27 Jun 2017 04:53:04 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE73129AB5 for ; Tue, 27 Jun 2017 04:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6919; q=dns/txt; s=iport; t=1498564383; x=1499773983; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=mAzW8AVk5/tFKsuIVhZJTn6/xrw3Zev+i609gBWcewI=; b=YXoVQJnG4LYhzxd5S4o+NS0TM1qB6a5Uz9m2/G+lTFXnywUgl9BhqUZv +q7xAsUxcWWXhl4lRgPkV9NIMAFtmm/6x6FEhkJfDfSSvqOH1STRPadCs gzm1OtqNfMPyTml51jFNZAYiTjUoIEjoMisP2CyqpvYT8rItahkkp3+pv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQBWRlJZ/xbLJq1GFhoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYVJg2yKGXOQcZBShSuCEYYpAoM4GAECAQEBAQEBAWsohRkBBSNmCxg?= =?us-ascii?q?TFwICVwYBDAYCAQGKLLACgiYpizUBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyeDT?= =?us-ascii?q?IIMgnmBPIJ1KYMjgmEFkEWOKop3iHSCCoVJg0uGdoxViE8fOIEKMCEIGxWFXwc?= =?us-ascii?q?QgWc/NokcAQEB?= X-IronPort-AV: E=Sophos;i="5.39,399,1493683200"; d="scan'208,217";a="653888609" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 11:53:01 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v5RBqwiB002602; Tue, 27 Jun 2017 11:53:01 GMT To: "Ogaki, Kenichi" , stephane.litkowski@orange.com, "'Qin Wu'" , l3sm@ietf.org References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> <00b101d2ee2b$8ef28ab0$acd7a010$@kddi.com> From: David Ball Message-ID: <0ed5e7de-9ab3-19a9-06ba-f0ec8a83c658@cisco.com> Date: Tue, 27 Jun 2017 12:52:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <00b101d2ee2b$8ef28ab0$acd7a010$@kddi.com> Content-Type: multipart/alternative; boundary="------------F8BEAD9B1505CAC1FD12216B" Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 11:53:06 -0000 This is a multi-part message in MIME format. --------------F8BEAD9B1505CAC1FD12216B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks Kenichi - there is one of your answers that I'm still confused about, see below: On 26/06/2017 04:23, Ogaki, Kenichi wrote: >>> 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. >>> >>> >>> [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] >> 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. 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 --------------F8BEAD9B1505CAC1FD12216B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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


On 26/06/2017 04:23, Ogaki, Kenichi wrote:
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.


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

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
<daviball@cisco.com>
--------------F8BEAD9B1505CAC1FD12216B-- From nobody Tue Jun 27 19:31:00 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35392129AB5 for ; Tue, 27 Jun 2017 19:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSI8QzqjOqyV for ; Tue, 27 Jun 2017 19:30:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5666B127ABE for ; Tue, 27 Jun 2017 19:30:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPY35744; Wed, 28 Jun 2017 02:30:53 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 28 Jun 2017 03:30:52 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 28 Jun 2017 10:30:48 +0800 From: Qin Wu To: David Ball , "stephane.litkowski@orange.com" , "Ogaki, Kenichi (ke-oogaki@kddi.com)" , "l3sm@ietf.org" Thread-Topic: [L3sm] Next Step of RFC8049 Thread-Index: AdLIzCXxBcQvJgePTDyhRzLdDi5cBQSos+gAARZ7BwAA32+/gABZEcKAAT9R1QAAIlktAAA3gU2AAF1OwTAAnJ9CgAAuvMkw Date: Wed, 28 Jun 2017 02:30:47 +0000 Message-ID: References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> <4f3c76b7-2e8d-4736-3107-9275e732c425@cisco.com> In-Reply-To: <4f3c76b7-2e8d-4736-3107-9275e732c425@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.595314DD.00FB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 09cd5f5c66d70c8f50c2790042f914ea Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 02:30:59 -0000 VGhhbmtzIERhdmlkLCBwbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZSBiZWxvdyB0YWdnZWQgd2l0 aCBbUWluLTFdDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogRGF2aWQgQmFs bCBbbWFpbHRvOmRhdmliYWxsQGNpc2NvLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTflubQ25pyI Mjfml6UgMTk6NDINCuaUtuS7tuS6ujogUWluIFd1OyBzdGVwaGFuZS5saXRrb3dza2lAb3Jhbmdl LmNvbTsgT2dha2ksIEtlbmljaGkgKGtlLW9vZ2FraUBrZGRpLmNvbSk7IGwzc21AaWV0Zi5vcmcN CuS4u+mimDogUmU6IFtMM3NtXSBOZXh0IFN0ZXAgb2YgUkZDODA0OQ0KDQpUaGFua3MgUWluIC0g bW9yZSBiZWxvdyB0YWdnZWQgd2l0aCBbREI0XS4NCg0KDQpPbiAyNC8wNi8yMDE3IDEwOjE4LCBR aW4gV3Ugd3JvdGU6DQo+DQo+Pj4gCTMuCVNvbWV3aGF0IHJlbGF0ZWQsIEkgYW0gdHJ5aW5nIHRv IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHNpdGUgd2l0aCBzdWItVlBOcyAo aS5lLiBlYWNoIHNpdGUtYWNjZXNzLWxpbmsgaXMgY29ubmVjdGVkIHRvIGEgZGlmZmVyZW50IFZQ TikgdnMgdHJlYXRpbmcgaXQgYXMgdHdvIHNpdGVzLCBlYWNoIHdpdGggYSBzaW5nbGUgc2l0ZS1h Y2Nlc3MtbGluay4gIFRoZSB0ZXh0IHNheXMgYSBzdWItVlBOICJpcyBzaW1pbGFyIHRvIGhhdmlu ZyBzZXBhcmF0ZSBzaXRlcywgYnV0IGluIHRoaXMgY2FzZSB0aGUgY3VzdG9tZXIgd2FudHMgdG8g c2hhcmUgc29tZSBwaHlzaWNhbCBjb21wb25lbnRzIHdoaWxlIG1haW50YWluaW5nIHN0cm9uZyBj b21tdW5pY2F0aW9uIGlzb2xhdGlvbiIuICBEb2VzICJ0aGlzIGNhc2UiIG1lYW4gdGhlIHN1Yi1W UE4gY2FzZSBvciB0aGUgbXVsdGlwbGUgc2l0ZXMgY2FzZT8gIEVpdGhlciB3YXksIHRoZSBjdXN0 b21lciBjb3VsZCBzaGFyZSBwaHlzaWNhbCBjb21wb25lbnRzIGFuZCBtYWludGFpbiBzdHJvbmcg aXNvbGF0aW9uLCByaWdodD8NCj4+PiAJDQo+Pj4gCQlbS09dIFRoaXMgY2FzZSBtZWFucyB0aGUg c3ViLVZQTiBjYXNlLCBhbmQgeW91ciBpbmRpY2F0aW9uIGlzIHJpZ2h0Lg0KPj4+DQo+Pj4NCj4+ PiBbREJdLiAgT2sgLSBpZiBpdCB0aGUgc2FtZSBhcyB1c2luZyBtdWx0aXBsZSBzaXRlcyAod2hp Y2ggd291bGQgc3RpbGwgYmUgdG9wb2xvZ2ljYWxseSBzZXBhcmF0ZSBldmVuIGlmIHRoZXkgdXNl IHRoZSBzYW1lIHBoeXNpY2FsIGNvbXBvbmVudHMpLCBJIGd1ZXNzIEkgZG9uJ3QgdW5kZXJzdGFu ZCB0aGUgcHVycG9zZSBvZiBoYXZpbmcgc3ViLVZQTiBhcyBhbiBvcHRpb24gLSBidXQgZ29vZCB0 byBrbm93IHRoZXJlIGlzIG5vdGhpbmcgZXh0cmEgSSdtIG1pc3NpbmcgaGVyZS4NCj4+Pg0KPj4+ IFtLT10gU3ViLVZQTiBpcyBhIHJlYWwtbGlmZSB1c2VjYXNlIHByb3ZpZGVkIGluIGNvbW1lcmNp YWwgVlBOIHNlcnZpY2VzLg0KPj4gW0RCMl0NCj4+IFN1cmUsIEkgYW0gbm90IGRpc3B1dGluZyB0 aGF0IHRoaXMgc2V0LXVwIGV4aXN0czsgbXkgcXVlc3Rpb24gaXMgd2h5IA0KPj4gaXQgc2hvdWxk IGJlIG1vZGVsbGVkIGFzIGEgc3ViLVZQTiBpbnN0ZWFkIG9mIG1vZGVsbGluZyBhdCBzZXBhcmF0 ZSBzaXRlcz8NCj4+IFRoZSBzYW1lIHNjZW5hcmlvIGNhbiBiZSBleHByZXNzZWQgZWl0aGVyIHdh eSwgcmlnaHQ/DQo+Pg0KPj4gW1NMSV0gV2UgaGFkIHRoaXMgZGViYXRlIGVhcmxpZXIgd2hlbiBt b2RlbGluZyB0aGUgc3ViVlBOICh1c2luZyBtdWx0aXBsZSBzaXRlcyB3YXMgb25lIG9mIHRoZSBw b3NzaWJpbGl0eSBidXQgbm90IHJldGFpbmVkKS4NCj4+IFRoZSBzdWJWUE5zIGhhcyB0aGUgcGFy dGljdWxhcml0eSBvZiBzaGFyaW5nIGEgY29tbW9uIGJlYXJlciBhbmQgYSBjb21tb24gQ1BFIChp dCdzIGEgVlJGIGxpdGUgQ1BFIGluIHRlcm0gb2YgY29uZmlndXJhdGlvbikuDQo+IFtEQjNdDQo+ IEkgYWdyZWUgdGhhdCB0d28gc2l0ZSBuZXR3b3JrIGFjY2Vzc2VzIGluIHRoZSBzYW1lIHNpdGUg YW5kIHVzaW5nIGEgc3ViVlBOIGNhbiBzaGFyZSBhIGNvbW1vbiBiZWFyZXIgYW5kIGEgY29tbW9u IENQRSwgYnV0IHR3byBzaXRlLW5ldHdvcmstYWNjZXNzZXMgaW4gZGlmZmVyZW50IHNpdGVzIGNv dWxkIGFsc28gc2hhcmUgYSBjb21tb24gYmVhcmVyIGFuZCBhIGNvbW1vbiBDUEUsIHJpZ2h0PyAg UGVyIHlvdXIgYW5zd2VyIGFib3ZlLCB0aGUgc2l0ZSBpcyBhIG5vdGlvbiBkZWZpbmVkIGJ5IHRo ZSBjdXN0b21lciwgc28gY291bGRuJ3QgdGhleSBkZXNpZ25hdGUgdHdvIHNpdGUgbmV0d29yayBh Y2Nlc3NlcyBhcyBiZWluZyBpbiBkaWZmZXJlbnQgc2l0ZXMgZXZlbiBpZiB0aGV5IHNoYXJlIHRo ZSBzYW1lIGJlYXJlcj8NCj4NCj4gSSB1bmRlcnN0YW5kIHdoYXQgc3ViVlBOICpjYW4qIGRvIC0g d2hhdCBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaXMgd2hldGhlciB0aGVyZSBpcyBhbnl0aGlu ZyB0aGF0ICpjYW4ndCogYmUgZG9uZSB3aXRoIG11bHRpcGxlIHNpdGVzLiBUaGUgdGV4dCBzdWdn ZXN0cyB0aGF0IHRoZXJlIGlzIHNvbWUgZnVuY3Rpb25hbCBkaWZmZXJlbmNlIGJldHdlZW4gdGhl c2UgdHdvIGFwcHJvYWNoZXMsIGJ1dCBpZiBzbywgSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgaXQg aXMuICBJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGVpdGhlciBtYWtlIHRoZSB0ZXh0IGNsZWFyZXIg YWJvdXQgdGhlIGRpZmZlcmVuY2UsIG9yIGVsc2UgY2hhbmdlIGl0IHRvIHNheSB0aGF0IHRoZSB0 d28gYXBwcm9hY2hlcyBhcmUgZnVuY3Rpb25hbGx5IHRoZSBzYW1lLg0KPg0KPiBbUWluXTogSG93 IGRvZXMgdHdvIHNpdGUtbmV0d29yay1hY2Nlc3MgYmVsb25naW5nIHRvIHR3byBkaWZmZXJlbnQg c2l0ZSBzaGFyZSB0aGUgc2FtZSBiZWFyZXIgb3IgcGh5c2ljYWwgY29tcG9uZW50Pw0KDQpbREI0 XQ0KU3RlcGhhbmUgc2FpZCBiZWZvcmUgIlRoZSBzaXRlIGlzIGEgbm90aW9uIHRoYXQgaXMgZGVm aW5lZCBieSB0aGUgY3VzdG9tZXIiLCBhbmQgZGVzY3JpYmVkIGhvdyBpdCBjb3VsZCBiZSBhIHNp bmdsZSBsb2NhdGlvbiBvciBtdWx0aXBsZSBsb2NhdGlvbnMuICBNeSBpbnRlcnByZXRhdGlvbiB3 YXMgdGhhdCBhICJzaXRlIiBpcyBpbmRlcGVuZGVudCBvZiBsb2NhdGlvbiwgc28gYXMgd2VsbCBh cyBoYXZpbmcgYSBzaW5nbGUgc2l0ZSBzcGFubmluZyBtdWx0aXBsZSBsb2NhdGlvbnMsIHlvdSBj b3VsZCBhbHNvIGhhdmUgYSBtdWx0aXBsZSBzaXRlcyBhdCBhIHNpbmdsZSBsb2NhdGlvbi4gIEkg dG9vayB0aGUgbWVhbmluZyB0byBiZTogYSBzaXRlIGlzIGFuIGFyYml0cmFyeSBjb2xsZWN0aW9u IG9mIHNpdGUgbmV0d29yayBhY2Nlc3NlcywgaW5kZXBlbmRlbnQgb2YgaG93IG9yIHdoZXJlIHRo ZXkgYXJlIGNvbm5lY3RlZC4gIFdpdGggdGhpcyBpbnRlcnByZXRhdGlvbiwgSSBkb24ndCBzZWUg YW55IHByb2JsZW1zIHdpdGggdHdvIHNpdGUtbmV0d29yay1hY2Nlc3NlcywgYmVsb25naW5nIHRv IHR3byBkaWZmZXJlbnQgInNpdGVzIiBidXQgY29ubmVjdGluZyB0byB0aGUgc2FtZSBsb2NhdGlv biwgc2hhcmluZyB0aGUgc2FtZSBiZWFyZXIgKGUuZy4gZGlmZmVyZW50IFZMQU5zIG9uIHRoZSBz YW1lIHBoeWlzY2FsIEV0aGVybmV0IGxpbmspLg0KDQpCdXQgcGVyaGFwcyBJIGhhdmUgZXh0cmFw b2xhdGVkIHRvbyBmYXIgZnJvbSB3aGF0IFN0ZXBoYW5lIHNhaWQ/ICBJcyB0aGUgaW50ZW50IHRo YXQgYSBnaXZlbiBsb2NhdGlvbiBjYW4gb25seSBoYXZlIGEgc2luZ2xlIHNpdGUgKGJ1dCBhIHNp dGUgY2FuIHNwYW4gbXVsdGlwbGUgbG9jYXRpb25zKT8NCg0KSW4gYW55IGNhc2UsIEkgdGhpbmsg dGhlIFJGQyB3b3VsZCBiZW5lZml0IGZyb20gc29tZSBjbGVhcmVyIGRlc2NyaXB0aW9uIG9mIGV4 YWN0bHkgd2hhdCBpcyBtZWFudCBieSBhICJzaXRlIi4NCg0KW1Fpbi0xXTpZZXMsIEluZGVlZCwg eW91IGV4dHJhcG9sYXRlIHRvbyBtdWNoLDotKSwgd2Ugd2lsbCBhZGQgYSBmZXcgdGV4dCB0byBj bGFyaWZ5IHdoYXQgdGhlIHNpdGUgaXMuIFRoYW5rcyENCg0KPj4+IAk1LglGb3IgY2xvdWQgYWNj ZXNzLCBhIHNpbmdsZSBWUE4gY2FuIGNvbm5lY3QgdG8gbXVsdGlwbGUgY2xvdWQgc2VydmljZXMs IGFuZCBmb3IgZWFjaCBjbG91ZCBzZXJ2aWNlIHlvdSBoYXZlIHRvIHNwZWNpZnkgd2hpY2ggc2l0 ZXMgYXJlIGF1dGhvcml6ZWQgdG8gYWNjZXNzIHRoZSBjbG91ZC4gIElzIHRoZXJlIGEgcmVhc29u IGl0IHdhcyBtb2RlbGxlZCB0aGlzIHdheSwgcmF0aGVyIHRoYW4gaGF2aW5nIGEgc2VwYXJhdGUg VlBOIHNlcnZpY2UgdG8gY29ubmVjdCB0byBlYWNoIGNsb3VkIHNlcnZpY2U/ICBJZiB0aGVyZSB3 YXMgYSBzZXBhcmF0ZSBWUE4gc2VydmljZSBmb3IgZWFjaCBjbG91ZCBzZXJ2aWNlLCB0aGVuIG9u bHkgdGhlIHJpZ2h0IHNpdGVzIHdvdWxkIGJlIGF0dGFjaGVkIHRvIHRoZSBWUE4gZm9yIGVhY2gg Y2xvdWQsIGFuZCBpdCB3b3VsZCBub3QgYmUgbmVjZXNzYXJ5IHRvIGhhdmUgYSBzZXBhcmF0ZSBs aXN0IG9mIGF1dGhvcml6ZWQgc2l0ZXMsIHJpZ2h0Pw0KPj4+IAkJDQo+Pj4gCVtLT10gVGhhdCdz IHJpZ2h0Lg0KPj4+DQo+Pj4NCj4+PiBbREJdIFNvIGlzIHRoZXJlIGEgcmVhc29uIGl0IHdhcyBu b3QgZG9uZSB0aGF0IHdheT8NCj4+Pg0KPj4+IFtLT10gVGhlIHJlcXVpcmVtZW50IHRoYXQgYSBW UE4gd2FudCB0byBjb25uZWN0IG11bHRpcGxlIGNsb3VkcyBzdGlsbCBleGlzdHMuIFRoZSBsYXR0 ZXIgY2FzZSBjYW5ub3QgY292ZXIgdGhpcy4NCj4+IFtEQjJdDQo+PiBDYW4geW91IGdpdmUgYW4g ZXhhbXBsZSB0aGF0IGNhbiBiZSBtb2RlbGxlZCB3aXRoIG11bHRpcGxlIGNsb3VkcyBpbiANCj4+ IGEgc2luZ2xlIFZQTiB0aGF0IGNvdWxkIG5vdCBiZSBtb2RlbGxlZCBhcyBtdWx0aXBsZSBWUE5z Pw0KPj4NCj4+IFtTTEldIFVzaW5nIG11bHRpcGxlIFZQTnMgaGFzIGEgbWFqb3IgaW1wYWN0IG9u IHRoZSBzZXJ2aWNlIGRlc2lnbiAobm90IHRhbGtpbmcgYWJvdXQgaW1wbGVtZW50YXRpb24pLiBG cm9tIGEgc2VydmljZSBwZXJzcGVjdGl2ZSwgbGV0J3Mgc2F5IHRoYXQgdGhlIGN1c3RvbWVyIHN0 YXJ0cyB3aXRoIGFuIGFueSB0byBhbnkgVlBOIHdoZXJlIGFsbCBzaXRlcyBjYW4gY29tbXVuaWNh dGUgd2l0aCBlYWNoIG90aGVyLg0KPj4gQWZ0ZXIgc29tZSBtb250aHMsIGl0IHJlcXVpcmVzIGEg Y2xvdWQgaW50ZXJjb25uZWN0aW9uLCBzbyBpdCdzIGh1YiBzaXRlIGNhbiBzcGF3biBWTSBpbiBB V1MgZm9yIGV4YW1wbGUgYnV0IHRoZSBvdGhlciBzaXRlcyBzaG91bGQgbm90IGFjY2VzcyB0byBB V1MuIEZyb20gYSBzZXJ2aWNlIHBlcnNwZWN0aXZlLCB5b3UgbmVlZCB0byBtb2RlbCBpdCBhcyBh IGxpc3Qgb2YgYXV0aG9yaXplZC91bmF1dGhvcml6ZWQgc2l0ZXMuDQo+PiBOb3cgaW4gdGVybSBv ZiBpbXBsZW1lbnRhdGlvbiwgeW91IGNhbiBkbyB3aGF0IHlvdSB3YW50LCB5b3UgY2FuIGNyZWF0 ZSBhZGRpdGlvbmFsIFZQTnMsIHlvdSBjYW4gdXNlIEFDTHMgb3Igd2hhdGV2ZXIuLi4gYnV0IGZy b20gYSBzZXJ2aWNlIHBlcnNwZWN0aXZlLCB0aGUgY3VzdG9tZXIgaGFzIGEgc2luZ2xlIFZQTiBh bmQgYSBjbG91ZCBhY2Nlc3Mgd2l0aCBsaW1pdGVkIGFjY2Vzcy4NCj4gW0RCM10NCj4gT2sgLSBi dXQgaW4gdGhpcyBzY2VuYXJpbywgd2h5IHdvdWxkbid0IHRoZSBjdXN0b21lciBqdXN0IGdldCBh IG5ldyBzZXJ2aWNlIGNvbm5lY3RpbmcgdGhlIGh1YiBzaXRlIHRvIHRoZSBjbG91ZCB3aGVuIHRo ZXkgbmVlZCBpdD8NCj4gSSBjYW4gc2VlIHdoeSBpdCBtaWdodCBiZSB0cmVhdGVkLCBjb21tZXJj aWFsbHksIGFzIHBhcnQgb2YgdGhlIHNhbWUgKnByb2R1Y3QqLCBidXQgSSBkb24ndCB1bmRlcnN0 YW5kIHdoeSBpdCB3b3VsZCBuZWVkIHRvIGJlIHRoZSBzYW1lICpzZXJ2aWNlKj8NCj4NCj4gW1Fp bl06VGhpcyBwcm92aWRlcyBmaW5lIGdyYW51bGFyaXR5IGNvbnRyb2wgb24gYSBzaXRlIGdldHRp bmcgYWNjZXNzIHRvIHB1YmxpYyBjbG91ZCBvciBpbnRlcm5ldC4NCj4gWW91IG1heSBhbHNvIGFk ZCBhIG5ldyBzaXRlIHRvIGFuIGV4aXN0aW5nIFZQTiwgYnV0IHRoaXMgc2l0ZSBtYXkgbm90IGhh dmUgYXV0aG9yaXphdGlvbiB0byBnZXQgYWNjZXNzIHRvIHB1YmxpYyBjbG91ZCB1bmxlc3MgeW91 IGV4cGxpY2l0bHkgY29uZmlndXJlIGl0Lg0KDQpbREI0XQ0KT2sgLSBzbyB0aGUgc2FtZSBmdW5j dGlvbmFsaXR5IGNvdWxkIGJlIGFjaGlldmVkIGJ5IGp1c3QgYWRkaW5nIGEgbmV3IFZQTiBpbiB0 aGlzIGNhc2UsIGJ1dCBJIGd1ZXNzIHRoZSBwb2ludCBpcyB0aGF0IGl0J3MgZWFzaWVyIHRvIG1h bmFnZSB0aGlzIHdheT8NCg0KW1Fpbi0xXSBJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Qs IE91ciBhc3N1bXB0aW9uLCBpcyBvbmUgVlBOIHNlcnZpY2UgY2FuIHByb3ZpZGUgYWNjZXNzIHRv IHB1YmxpYyBjbG91ZCBhbmQgcHJvdmlkZSBjbG91ZCwgZGF0YSBjZW50ZXIgbmV0d29yaywgd2Ug ZG9uJ3QgZGVlbSBwcm92aWRpbmcgYWNjZXNzIHRvIHB1YmxpYyBjbG91ZCBhcyBhIG5ldyBWUE4g c2VydmljZSwNCkluc3RlYWQsIGl0IGlzIHBhcnQgb2YgZXhpc3RpbmcgVlBOIHNlcnZpY2UuDQpN YXliZSB5b3UganVzdCBoYXZlIGRpZmZlcmVudCBtb2RlbCBkZXNpZ24uDQoNCj4+PiAJMTAuCVRo ZXJlIGlzIGEgcW9zLWNsYXNzaWZpY2F0aW9uLXBvbGljeSAoZWl0aGVyIHBlci1zaXRlIG9yIHBl ci1zaXRlLW5ldHdvcmstYWNjZXNzKSwgd2hpY2ggZGVzY3JpYmVzIGhvdyB0byBtYXAgcGFja2V0 cyB0byB0aGUgcmlnaHQgY2xhc3Mgb2Ygc2VydmljZS4gIEluIGEgc2luZ2xlLVZQTiBjYXNlLCB0 aGlzIGlzIGZpbmUsIGJ1dCBJIGFtIG5vdCBzdXJlIGhvdyB0byBpbnRlcnByZXQgaXQgd2hlbiB0 aGUgc2l0ZSBpcyBhdHRhY2hlZCB0byBtdWx0aXBsZSBWUE5zLiAgVGhlIGRpZmZlcmVudCBWUE5z IG1pZ2h0IGhhdmUgZGlmZmVyZW50IGNsYXNzZXMgb2Ygc2VydmljZSwgc28gZG9lc24ndCB0aGUg Y2xhc3NpZmljYXRpb24gcG9saWN5IG5lZWQgdG8gYmUgcGVyLXNpdGUgcGVyLVZQTiwgbm90IGp1 c3QgcGVyLXNpdGU/DQo+Pj4gCQ0KPj4+IAlbS09dIEFzIGRlc2NyaWJlZCBpbiA2LjEyLjIuMSwg d2hlcmUgdG8gY2xhc3NpZnkgYW5kIGFwcGx5IHRoZSBxb3MgaXMgdXAgdG8gdGhlIFNQLCBhbmQg b3V0c2lkZSBvZiBzY29wZSBvZiB0aGlzIG1vZGVsLg0KPj4+DQo+Pj4NCj4+PiBbREJdIEFncmVl ZCwgYnV0IHRoYXQgd2Fzbid0IG15IHF1ZXN0aW9uLiAgVGhlIHF1ZXN0aW9uIGlzLCBpbiBhIG11 bHRpLVZQTiBjYXNlLCBkb24ndCB5b3Ugd2FudCBhIGRpZmZlcmVudCBRb1MgcG9saWN5IGZvciBl YWNoIFZQTiBhdCB0aGUgc2l0ZT8NCj4+Pg0KPj4+IFtLT10gQXMgSSB3cm90ZSBiZWxvdywgd2Ug bmVlZCBhdCBsZWFzdCBjbGFzc2lmeS9hcHBseSBhIHFvcyBhdCBpbnB1dC9vdXRwdXQgb2YgUEUs IG5vdCBkaWZmZXJlbnRpYXRlIGl0IHBlciBWUE4uIEJ1dCwgb3RoZXIgU1BzIG1heSB3YW50IHRo aXMuDQo+PiBbREIyXSBSaWdodCAtIHNvIHNob3VsZG4ndCB0aGUgbW9kZWwgc3VwcG9ydCBpdD8N Cj4+IFtTTEldIEknbSBub3Qgc3VyZSB0aGlzIGlzIG5lY2Vzc2FyeSwgaW4gdGhlIG11bHRpVlBO IGNhc2UsIHRoZSBzaXRlIGlzICJzaGFyZWQiLCBzbyB0aGUgY3VzdG9tZXIgZXhwZWN0cyBmbG93 cyB0byBnbyB0byBzaXRlcyB0aGF0IGFyZSBsb2NhdGVkIGluIGRpZmZlcmVudCBWUE5zLiBUaGUg Y3VzdG9tZXIgY2FuIHVzZSB0aGUgZHN0LXByZWZpeCBvciB0aGUgdGFyZ2V0LXNpdGUgaW4gb3Jk ZXIgdG8gc2V0IGEgcGFydGljdWxhciBjbGFzcyBmb3IgYSBwYXJ0aWN1bGFyIGZsb3cgd2hhdGV2 ZXIgdGhlIFZQTi4NCj4gW0RCM10NCj4gUmlnaHQsIGJ1dCBpdCB3b3VsZCBiZSB2ZXJ5IGVhc3kg d2l0aCB0aGlzIG1lY2hhbmlzbSBmb3IgdGhlIGN1c3RvbWVyIHRvIG1ha2UgYSBtaXN0YWtlIGFu ZCBoYXZlIGEgcG9saWN5IHRoYXQgbWFwcyBhIHBhY2tldCB0aGF0IHdpbGwgZ28gdG8gYSBzaXRl IGluIG9uZSBWUE4gdG8gYSBjbGFzcyB0aGF0IG9ubHkgZXhpc3RzIGluIHRoZSBvdGhlciBWUE47 IGFuZCBtb3Jlb3ZlciwgaXQgd291bGQgYmUgaGFyZCBmb3IgdGhlIFNQIHRvIGNoZWNrIHRoaXMu IFdvdWxkIGl0IG5vdCBiZSBiZXR0ZXIgdG8gZGVzaWduIHRoZSBtb2RlbCBzbyB0aGF0IHRoZXNl IHNvcnRzIG9mIGNvbnNpc3RlbmN5IGNoZWNrcyBhcmUgaW1wbGljaXQgaW4gdGhlIHN0cnVjdHVy ZSBvZiB0aGUgbW9kZWwsIHJhdGhlciB0aGFuIHJlbHlpbmcgb24gdGhlIGN1c3RvbWVyIG5vdCB0 byBtYWtlIGEgbWlzdGFrZT8NCj4NCj4gT2YgY291cnNlLCBpZiBhbGwgdGhlIFZQTnMgaGF2ZSB0 aGUgc2FtZSBzZXQgb2YgY2xhc3NlcywgdGhlbiB0aGVyZSBpcyBubyBpc3N1ZS4gIFBlcmhhcHMg dGhhdCBpcyB0aGUgY29tbW9uIGNhc2U/DQo+DQo+IFtRaW5dOiBBdHRhY2hpbmcgc2l0ZSB0byBh cHByb3ByaWF0ZSBWUE4gaXMgcmVhbGl6ZWQgdXNpbmcgdnBuLWF0dGFjaG1lbnQsIGVpdGhlciBy ZWZlcmVuY2luZyBWUE4gZGlyZWN0bHkgb3IgcmVmZXJlbmNpbmcgdnBuIHBvbGljeS4gSW4gdGhh dCB3YXksIHNpdGUgd2lsbCBrbm93IHRvIHdoaWNoIFZQTiB0aGUgcGFja2V0IHNob3VsZCBiZSBm b3J3YXJkZWQuDQoNCltEQjRdDQpZZXMgLSB0aGUgcXVlc3Rpb24gd2FzIG5vdCBhYm91dCBmb3J3 YXJkaW5nIHRoZSBwYWNrZXQsIGJ1dCBhYm91dCBhcHBseWluZyB0aGUgUW9TIHBvbGljeS4NCg0K UGVyaGFwcyBhbiBleGFtcGxlIHdpbGwgaGVscCB0byBjbGFyaWZ5IHRoZSBzY2VuYXJpbyBJJ20g dGhpbmtpbmcgb2YuDQoNClN1cHBvc2UgSSBoYXZlIHR3byBWUE5zLCAiZm9vIiBhbmQgImJhciIu ICBBdCBhIHBhcnRpY3VsYXIgc2l0ZSwgSSB1c2UgdGhlIFZQTiBwb2xpY3kgdG8gYXR0YWNoIHRo ZSBzaXRlIHRvIGJvdGggImZvbyIgYW5kICJiYXIiLCBhcyBhIG11bHRpVlBOIGF0dGFjaG1lbnQu DQoNClZQTiAiZm9vIiBoYXMgdGhyZWUgY2xhc3NlcyBvZiBzZXJ2aWNlLCBjYWxsZWQgSCwgTSBh bmQgTC4NClZQTiAiYmFyIiBhbHNvIGhhcyB0aHJlZSBjbGFzc2VzIG9mIHNlcnZpY2UsIGNhbGxl ZCBzcXVhcmUsIGNpcmNsZSBhbmQgdHJpYW5nbGUuDQoNCk5vdywgZm9yIHBhY2tldHMgdGhhdCBh cmUgbWFwcGVkIHRvIFZQTiAiZm9vIiAocGVyIHRoZSBWUE4gcG9saWN5KSwgSSBuZWVkIHRvIHNl dCBhIFFvUyBjbGFzc2lmaWNhdGlvbiBwb2xpY3kgd2l0aCB0YXJnZXQgY2xhc3NlcyBILCBNIGFu ZCBMLiAgDQpCdXQsIGZvciBwYWNrZXRzIHRoYXQgYXJlIG1hcHBlZCB0byBWUE4gImJhciIgKHBl ciB0aGUgVlBOIHBvbGljeSksIEkgbmVlZCB0byBzZXQgYSBRb1MgY2xhc3NpZmljYXRpb24gcG9s aWN5IHdpdGggdGFyZ2V0IGNsYXNzZXMgc3F1YXJlLCBjaXJjbGUgYW5kIHRyaWFuZ2xlLiAgSG93 ZXZlciwgd2l0aCB0aGUgbW9kZWwgaXQgaXMgb25seSBwb3NzaWJsZSB0byBoYXZlIGEgc2luZ2xl IFFvUyBjbGFzc2lmaWNhdGlvbiBwb2xpY3kgZm9yIHRoZSB3aG9sZSBzaXRlLiAgU28sIEkgbXVz dCBjb25maWd1cmUgYSBwb2xpY3kgdGhhdCBoYXMgYWxsIHNpeCB0YXJnZXQgY2xhc3NlcyAoSCwg TSwgTCwgY2lyY2xlLCBzcXVhcmUgYW5kIHRyaWFuZ2xlKSBhbmQgdHJ5IHRvIGVuc3VyZSB0aGF0 IHBhY2tldHMgdGhhdCB3aWxsIGJlIG1hcHBlZCB0byBWUE4gImZvbyIgZ2V0IHRhcmdldCBjbGFz cyBILCBNIG9yIEwgYW5kIHBhY2tldHMgdGhhdCB3aWxsIGJlIG1hcHBlZCB0byBWUE4gImJhciIg Z2V0IHRhcmdldCBjbGFzcyBjaXJjbGUsIHNxdWFyZSBvciB0cmlhbmdsZS4gIFRoaXMgaXMgdmVy eSBoYXJkIHNpbmNlIHdoaWNoIFZQTiB0aGUgcGFja2V0cyBnZXQgbWFwcGVkIHRvIGRlcGVuZHMg b24gcm91dGluZyBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgZHluYW1pYy4NCg0KSSBrbm93IHRoaXMg aXMgYSBjb250cml2ZWQgZXhhbXBsZSwgYnV0IHlvdSBjYW4gZWFzaWx5IHRoaW5rIG9mIG1vcmUg cmVhbGlzdGljIGNhc2VzLCBlLmcuIHRoZSBzaXRlIGlzIGF0dGFjaGVkIHRvIGJvdGggYSBWUE4g c2VydmljZSB3aXRoIEVGLCBBRiBhbmQgQkUgY2xhc3NlcyBhbmQgYWxzbyBhdHRhY2hlZCB0byBh biBpbnRlcm5ldCBhY2Nlc3Mgc2VydmljZSB0aGF0IG9ubHkgaGFzIGEgc2luZ2xlIGNsYXNzLiAN Cg0KW1Fpbi0xXTogWW91IGZvcmdldCB0aGF0IHdlIGFsc28gaGF2ZSB0YXJnZXQtc2l0ZXMgZGVm aW5lZCB1bmRlciAncW9zLWNsYXNzaWZpY2F0aW9uLXBvbGljeScsIHRhcmdldC1zaXRlcyB3aWxs IGJlIGFuIGFsdGVybmF0aXZlIHdheSB0byBpZGVudGlmeSB0aGUgZGVzdGluYXRpb24gb2YgYSBm bG93IHRhcmdldGVkIHRvIHNwZWNpZmljIFZQTiBiZXNpZGVzIHVzaW5nIGRlc3RpbmF0aW9uIGFk ZHJlc3MsIFZQTi1hdHRhY2htZW50IHRlbGwgdXMgd2hpY2ggc2l0ZSBpcyBhdHRhY2hlZCB0byB3 aGljaCBWUE4sIG5vIG1hdHRlciB3aGV0aGVyIG9uZSBzaXRlIGlzIGF0dGFjaGVkIHRvIG9uZSBW UE4sIG9yIHR3byBWUE5zLiBDb21iaW5pbmcgVlBOLWF0dGFjaG1lbnQgYW5kIHRhcmdldC1zaXRl cywgd2Ugd2lsbCBrbm93IGhvdyB0byBtYXAgc3BlY2lmaWMgVlBOKEluZGljYXRlZCBieSB0YXJn ZXQgc2l0ZXMpIHRvIHNwZWNpZmljIHRhcmdldCBjbGFzcy4gRWFjaCBzaXRlIHdpbGwgYWxzbyBr bm93IGhvdyB0byBjb3JyZWN0bHkgYXBwbHkgUW9TIHBvbGljeS4NCg0KPj4+IAkxMi4JT24gc2lt aWxhciBsaW5lcywgaW4gdGhlIHFvcy1wcm9maWxlIHRoZXJlIGlzIGEgZ3VhcmFudGVlZC1iYW5k d2lkdGgsIHdoaWNoIGNhbiBlaXRoZXIgYmUgZm9yIGp1c3QgdGhlIGFjY2Vzcywgb3IgY2FuIGJl IGVuZC10by1lbmQuICBIb3cgc2hvdWxkIGFuIGVuZC10by1lbmQgYmFuZHdpZHRoIGd1YXJhbnRl ZSBiZSBpbnRlcnByZXRlZCBpZiB0aGUgVlBOIGhhcyBtb3JlIHRoYW4gdHdvIHNpdGVzPyAgT3Ig ZG9lcyBpdCBvbmx5IG1ha2Ugc2Vuc2UgZm9yIGEgUDJQIGNhc2U/DQo+Pj4gCQkNCj4+PiAJW0tP XSBTYW1lIGNvbW1lbnQgYXMgYWJvdmUuIEFzIEkga25vdywgYSBTUCBjb250cm9scyB0aGUgYmFu ZHdpZHRoIGF0IGlucHV0L291dHB1dCBvZiBQRS4NCj4+Pg0KPj4+DQo+Pj4gW0RCXSBBZ3JlZWQg LSBidXQgYWdhaW4sIHRoZSBxdWVzdGlvbiBpcyBhYm91dCB0aGUgbWVhbmluZyBvZiB0aGUgYXR0 cmlidXRlIHJhdGhlciB0aGFuIHdoZXJlIHRoZSBTUCBpbXBsZW1lbnRzIGl0LiAgSW4gYSBWUE4g d2l0aCAxMCBzaXRlcywgd2hhdCBkb2VzIGl0IG1lYW4gdG8gc2F5IHRoYXQgdGhlIGVuZC10by1l bmQgYmFuZHdpZHRoIGlzIDEwTWIvcz8NCj4+Pg0KPj4+IFtLT10gRm9yIG91ciBjYXNlLCB0aGlz IG1lYW5zIG5vdCBhbiBlbmQtdG8tZW5kIHFvcywgYnV0IGFuIGFjY2VzcyBxb3MuIElmIGEgU1Ag d2FudHMgYW4gZW5kLXRvLWVuZCBxb3MsIGhlL3NoZSBtdXN0IG5lZ290aWF0ZSBzb21lIGNvbnN0 cmFpbnRzIG9yIGNvbmRpdGlvbnMgd2l0aCBoZXIvaGlzIGN1c3RvbWVyIG91dHNpZGUgb2YgdGhp cyBtb2RlbC4NCj4+IFtEQjJdIE15IHF1ZXN0aW9uIHdhcyBzcGVjaWZpY2FsbHkgYWJvdXQgd2hl biB0aGUgZW5kLXRvLWVuZCBsZWFmIGlzIA0KPj4gc2V0IHRvIHRydWUuDQo+Pg0KPj4gW1NMSV0g VGhlIG1haW4gdXNlIGNhc2UgaXMgUDJQLCBidXQgaWYgaXQgaXMgc2V0IGZvciBhIGNsYXNzIHdo aWNoIGludm9sdmVzIG1vcmUgdGhhbiB0d28gc2l0ZXMsIHRoZSByZXNlcnZhdGlvbiB3aWxsIGJl IGRvbmUgdG8gYWxsIHRoZSBzaXRlcyBpbnZvbHZlZC4NCj4gW0RCM10NCj4gU28sIGZvciBleGFt cGxlLCBzdXBwb3NlIEkgaGF2ZSBhIFZQTiB3aXRoIDUgc2l0ZXMsIHdpdGggdGhlIGZvbGxvd2lu Zw0KPiBzZXR0aW5nczoNCj4gICAgKiBTaXRlIEE6IHN2Yy1pbnB1dC1iYW5kd2lkdGggPSBzdmMt b3V0cHV0LWJhbmR3aWR0aCA9IDEwMDAwMDAwMCwgZm9yIGNsYXNzICJmb28iIGd1YXJhbnRlZWQt YnctcGVyY2VudCA9IDEwLCBlbmQtdG8tZW5kID0gdHJ1ZQ0KPiAgICAqIFNpdGUgQjogc3ZjLWlu cHV0LWJhbmR3aWR0aCA9IHN2Yy1vdXRwdXQtYmFuZHdpZHRoID0gMjAwMDAwMDAwLCBmb3IgY2xh c3MgImZvbyIgZ3VhcmFudGVlZC1idy1wZXJjZW50ID0gMjAsIGVuZC10by1lbmQgPSB0cnVlDQo+ ICAgICogU2l0ZSBDOiBzdmMtaW5wdXQtYmFuZHdpZHRoID0gc3ZjLW91dHB1dC1iYW5kd2lkdGgg PSAzMDAwMDAwMDAsIGZvciBjbGFzcyAiZm9vIiBndWFyYW50ZWVkLWJ3LXBlcmNlbnQgPSAzMCwg ZW5kLXRvLWVuZCA9IHRydWUNCj4gICAgKiBTaXRlIEQ6IHN2Yy1pbnB1dC1iYW5kd2lkdGggPSBz dmMtb3V0cHV0LWJhbmR3aWR0aCA9IDQwMDAwMDAwMCwgZm9yIGNsYXNzICJmb28iIGd1YXJhbnRl ZWQtYnctcGVyY2VudCA9IDQwLCBlbmQtdG8tZW5kID0gdHJ1ZQ0KPiAgICAqIFNpdGUgRTogc3Zj LWlucHV0LWJhbmR3aWR0aCA9IHN2Yy1vdXRwdXQtYmFuZHdpZHRoID0gNTAwMDAwMDAwLCANCj4g Zm9yIGNsYXNzICJmb28iIGd1YXJhbnRlZWQtYnctcGVyY2VudCA9IDUwLCBlbmQtdG8tZW5kID0g dHJ1ZQ0KPg0KPiBXaGF0IGRvZXMgdGhpcyBtZWFuPyAgV2hhdCBiYW5kd2lkdGggaXMgcmVzZXJ2 ZWQgYmV0d2VlbiBlYWNoIG9mIHRoZSAxMCBwYWlycyBvZiBzaXRlcz8NCj4NCj4gW1Fpbl06IHNl dCBlbmQgdG8gZW5kIGxlYWYgYXMgdHJ1ZSBtZWFucyBiYW5kd2lkdGggcmVzZXJ2YXRpb24gaXMg YXBwbGllZCB0byBlbmQgdG8gZW5kIGNvbm5lY3Rpdml0eSwgYWNyb3NzIE1QTFMgdHJhbnNwb3J0 IG5ldHdvcmsuDQo+IFNldCBlbmQgdG8gZW5kIGxlYWYgYXMgZmFsc2UgbWVhbnMgYmFuZHdpZHRo IHJlc2VydmF0aW9uIGlzIG9ubHkgYXBwbGllZCB0byBhY2Nlc3MgY29ubmVjdGl2aXR5IGZvciBj dXN0b21lciBzaXRlLg0KPiBDaG9vc2UgY2xhc3MgImZvbyIgd2l0aCBzcGVjaWZpYyB0YXJnZXQg c2l0ZSwgd2Uga25vdyBmcm9tIHdoaWNoIHNpdGUgdG8gd2hpY2ggc2l0ZSBiYW5kd2lkdGggcmVz ZXJ2YXRpb24gbmVlZHMgdG8gYmUgcGVyZm9ybWVkLg0KDQpbREI0XSBJZiB0aGUgU1AgcmVjZWl2 ZXMgYSByZXF1ZXN0IHdpdGggdGhlIGFib3ZlIGRhdGEsIHdoYXQgYmFuZHdpZHRoIGRvIHRoZXkg bmVlZCB0byByZXNlcnZlIGVuZC10by1lbmQgYmV0d2VlbiBBIGFuZCBCLCBvciBiZXR3ZWVuIEUg YW5kIEM/DQoNCltRaW4tMV06IEp1c3QgbGlrZSB3ZSB1c2UgUlNWUCBvciBSU1ZQLVRFIHRvIHJl c2VydmUgcmVzb3VyY2UgYWNyb3NzIG5ldHdvcmsuIElmIHdlIHNwZWNpZnkgdGFyZ2V0LXNpdGVz IHVuZGVyICcgcW9zLWNsYXNzaWZpY2F0aW9uLXBvbGljeSAnLCB3ZSB3aWxsIGtub3cgZnJvbSB3 aGljaCBzb3VyY2Ugc2l0ZSB0byB3aGljaCB0YXJnZXQgc2l0ZSB0aGUgYmFuZHdpZHRoIG5lZWRz IHRvIGJlIHJlc2VydmVkIGFjcm9zcyB0aGUgbmV0d29yay4gVGhlIHRhcmdldC1zaXRlcyBjb3Vs ZCBiZSBhIGxpc3QsZS5nLCBTaXRlIEEgaXMgdGhlIHNvdXJjZSBzaXRlLCBTaXRlQiwgU2l0ZSBE IGFyZSBwYXJ0IG9mIHRhcmdldC1zaXRlcyBsaXN0LCB3ZSBjYW4gcmVzZXJ2ZSB0aGUgc2FtZSBi YW5kd2lkdGggZnJvbSBTaXRlIEEgdG8gU2l0ZSBCIGFzIHRoZSBvbmUgZnJvbSBTaXRlIEEgdG8g U2l0ZSBELg0KDQo+Pj4gCTEzLglMb3RzIG9mIHF1ZXN0aW9ucyBhYm91dCB0aGUgcm91dGluZy1w cm90b2NvbHM6DQo+Pj4gCQ0KPj4+IAkJMS4JV2hlbiB0aGUgcm91dGluZyBwcm90b2NvbCBpcyAi ZGlyZWN0IiwgdGhlIFNQIHJvdXRlcyB0cmFmZmljIHRvd2FyZHMgdGhlIHByZWZpeCBzcGVjaWZp ZWQgYnkgdGhlIGNvbm5lY3Rpb24gYWRkcmVzczsgaG93ZXZlciwgb25lIHdvdWxkIGV4cGVjdCB0 aGF0IHRoZXkgYWx3YXlzIGRvIHRoaXMgcmVnYXJkbGVzcyBvZiB3aGF0IG90aGVyIHJvdXRpbmcg cHJvdG9jb2wgaXMgaW4gdXNlLCByaWdodD8gIFNvLCB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4gc3BlY2lmeWluZyByb3V0aW5nIHByb3RvY29sICJkaXJlY3QiLCBhbmQgbGVhdmluZyB0 aGUgcm91dGluZyBwcm90Y29sIGxpc3QgZW1wdHk/DQo+Pj4gCQ0KPj4+IAkNCj4+PiAJW0tPXSBU aGUgbGlzdCByb3V0aW5nLXByb3RvY29sIGhhcyB0aGUgZW50aXR5IHdpdGggInR5cGUiIGFzIHRo ZSBrZXkuIFRoZW4gZW1wdHkgcm91dGluZyBwcm90b2NvbCBpcyBub3QgYWxsb3dlZC4NCj4+Pg0K Pj4+DQo+Pj4gW0RCXSBJIG1lYW50IGFuIGVtcHR5IGxpc3QsIG5vdCBhbiBlbXB0eSBlbGVtZW50 IGluIHRoZSBsaXN0LiAgVGhlcmUgaXMgbm8gIm1pbi1lbGVtZW50cyIgb24gdGhlIHJvdXRpbmct cHJvdG9jb2wgbGlzdCwgc28gdGhlIGxpc3QgaXRzZWxmIGNvdWxkIGJlIGVtcHR5Lg0KPj4+DQo+ Pj4gW0tPXSBJIHVuZGVyc3RhbmQuIEkgdGhpbmsgaXQgc2hvdWxkIHNwZWNpZnkgdGhlICJtaW4t ZWxlbWVudHMiIHdpdGggb25lIGVudGl0eS4gQnV0LCB3ZSBtYXkgYmUgYWJsZSB0byB1bmRlcnN0 YW5kIHRoZSBjYXNlIGFzIHRoZSBkaXJlY3QsIGlmIHRoZSBsaXN0IGlzIGVtcHR5Lg0KPj4gW0RC Ml0gUmlnaHQgLSBzbyBpZiB0aGUgImRpcmVjdCIgY2FzZSBjYW4gYmUgcmVwcmVzZW50ZWQgYnkg YW4gZW1wdHkgDQo+PiBsaXN0LCB0aGVuIHRoZXJlIGlzIG5vIG5lZWQgdG8gZXhwbGljaXRseSBz cGVjaWZ5ICJkaXJlY3QiLg0KPj4NCj4+IFtTTEldIFNvbWUgU1BzIHByZXZlbnRzIHRvIGFkdmVy dGlzZSB0aGUgaW50ZXJjbyBzdWJuZXQgZXhjZXB0IGlmIHRoZSBjdXN0b21lciByZWFsbHkgcmVx dWlyZXMgaXQuDQo+IFtEQjNdDQo+IFNvcnJ5IEkgZGlkIG5vdCB1bmRlcnN0YW5kIGhvdyB0aGlz IHJlbGF0ZXMgdG8gdGhlIGlzc3VlPw0KPg0KPiBbUWluXTogV2h5IG5vdCBzcGVjaWZ5IGRpcmVj dCByb3V0ZSBpbiB0aGUgbW9kZWwgaWYgZGlyZWN0IHJvdXRlIG5lZWQgdG8gYmUgc3VwcG9ydGVk PyBXZSBjb3VsZCBhZCBtaW4tZWxlbWVudCAiMSIgdG8gbWFrZSBzdXJlIHRoZSBsaXN0IGNhbm5v dCBiZSBlbXB0eS4NCg0KW0RCNF0NCk15IG9waW5pb24gd291bGQgYmUgdGhlIG9wcG9zaXRlIC0g d2h5IGZvcmNlIGl0IHRvIGJlIHNwZWNpZmllZCBpZiBpdCdzIG5vdCBuZWVkZWQ/DQpQcm9iYWJs eSB0aGUgYmVzdCBvcHRpb24gaXMgdG8gbGVhdmUgaXQgYXMgaXQgaXMsIGkuZS4gaXQgY2FuIGJl IHNwZWNpZmllZCBvciBub3QuDQoNCltRaW4tMV06IEkgbGlrZSB0byBhcmd1ZSB3aHkgbm90IHJl c3BlY3QgZGlyZWN0IHJvdXRlIGFzIG1hbnkgb3RoZXIgb3B0aW9uYWwgcm91dGluZyBwcm90b2Nv bCBzdWNoIGFzIGJncCwgb3NwZi46LSkgIE1hbnkgVGhhbmtzIGZvciB5b3VyIHZhbHVhYmxlIGNv bW1lbnRzLg0KDQogICAgIERhdmlkDQoNCi0tDQpEYXZpZCBCYWxsDQo8ZGF2aWJhbGxAY2lzY28u Y29tPg0KDQo= From nobody Tue Jun 27 19:37:59 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88741126CC4 for ; Tue, 27 Jun 2017 19:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVv8pLjU0MmG for ; Tue, 27 Jun 2017 19:37:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A0E12717E for ; Tue, 27 Jun 2017 19:37:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPY36422; Wed, 28 Jun 2017 02:37:52 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 28 Jun 2017 03:37:51 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 28 Jun 2017 10:37:46 +0800 From: Qin Wu To: David Ball , "Ogaki, Kenichi" , "stephane.litkowski@orange.com" , "l3sm@ietf.org" Thread-Topic: [L3sm] Next Step of RFC8049 Thread-Index: AdLIzCXxBcQvJgePTDyhRzLdDi5cBQSos+gAARZ7BwAA32+/gABZEcKAAT9R1QAAIlktAAA3gU2AALY54IAARBcUgAAvcdig Date: Wed, 28 Jun 2017 02:37:46 +0000 Message-ID: References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> <00b101d2ee2b$8ef28ab0$acd7a010$@kddi.com> <0ed5e7de-9ab3-19a9-06ba-f0ec8a83c658@cisco.com> In-Reply-To: <0ed5e7de-9ab3-19a9-06ba-f0ec8a83c658@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A987485nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.59531680.008D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 09cd5f5c66d70c8f50c2790042f914ea Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 02:37:58 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9A987485nkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF2aWQ6DQpBIGZldyB0aG91Z2h0cyBhbmQgY29tbWVudHMgYmVsb3cuDQrlj5Hku7bkuro6IERh dmlkIEJhbGwgW21haWx0bzpkYXZpYmFsbEBjaXNjby5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTfl ubQ25pyIMjfml6UgMTk6NTMNCuaUtuS7tuS6ujogT2dha2ksIEtlbmljaGk7IHN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tOyBRaW4gV3U7IGwzc21AaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtM M3NtXSBOZXh0IFN0ZXAgb2YgUkZDODA0OQ0KDQoNClRoYW5rcyBLZW5pY2hpIC0gdGhlcmUgaXMg b25lIG9mIHlvdXIgYW5zd2VycyB0aGF0IEknbSBzdGlsbCBjb25mdXNlZCBhYm91dCwgc2VlIGJl bG93Og0KDQpPbiAyNi8wNi8yMDE3IDA0OjIzLCBPZ2FraSwgS2VuaWNoaSB3cm90ZToNCg0KNC4g ICBVbmRlciB0aGUgVlBOIHNlcnZpY2UsIHRoZXJlIGlzIGEgbGVhZiBmb3IgdGhlIGN1c3RvbWVy IG5hbWUuICBJZiB0aGUgbW9kZWwgaXMgc3VwcG9zZWQgdG8gcmVwcmVzZW50IHRoZSByZXF1ZXN0 IGZyb20gYSBjdXN0b21lciB0byB0aGUgU1AsIEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoZSBjdXN0 b21lciBuYW1lIHdvdWxkIGJlIGtub3duIG91dC1vZi1iYW5kLCBlLmcuIGZyb20gdGhlIEFBQSBm b3IgdGhlIHJlcXVlc3Q/ICBJdCB3b3VsZCBiZSBiYWQgaWYgb25lIGN1c3RvbWVyIGNvdWxkIHJl cXVlc3QgdGhpbmdzIGZvciBhbm90aGVyIGN1c3RvbWVyIGJ5IGZpbGxpbmcgaW4gYSBkaWZmZXJl bnQgY3VzdG9tZXIgbmFtZSBpbiB0aGUgbW9kZWwhDQoNCg0KDQogICAgIFtLT10gQSBjdXN0b21l ciBjYW4gb25seSBhY2Nlc3MgdGhlIG1vZGVsIGluc3RhbmNlIG9mIHRoYXQgY3VzdG9tZXIuIFBs ZWFzZSBzZWUgc2VjdGlvbiAxMC4NCg0KDQoNCg0KDQpbREJdIFllcyBleGFjdGx5IC0gaWYgYSBj dXN0b21lciBjYW4gb25seSBhY2Nlc3MgdGhlaXIgb3duIGluc3RhbmNlIG9mIHRoZSBtb2RlbCwg d2h5IGRvZXMgdGhlIGN1c3RvbWVyIG5hbWUgbmVlZCB0byBiZSBzcGVjaWZpZWQgd2l0aGluIHRo ZSBtb2RlbD8gIFlvdSBhbHJlYWR5IGtub3cgeW91IGFyZSBkZWFsaW5nIHdpdGggdGhhdCBjdXN0 b21lcidzIGluc3RhbmNlIG9mIHRoZSBtb2RlbC4gIEl0IHNlZW1zIGxpa2UgdGhlIGN1c3RvbWVy LW5hbWUgbGVhZiBpcyB1bm5lY2Vzc2FyeT8NCg0KDQoNCltLT10gQXMgY29tbW9uIHVzZWNhc2Vz LCBhIFZQTiBzZXJ2aWNlIGlzIHByb3ZpZGVkIG5vdCBvbmx5IGJ5IFRpZXIgMSBwcm92aWRlcnMs IGJ1dCBhbHNvIGJ5IFRpZXIgMiBwcm92aWRlcnMgb3IgSVQgZGl2aXNpb25zIG9mIGVudGVycHJp c2VzIGluIG9yZGVyIHRvIHByb3ZpZGUgdGhlaXIgb3duIGVuZCB1c2VycyBieSB1c2luZyBhIFRp ZXIgMSBwcm92aWRlcidzIFZQTiBzZXJ2aWNlLiBTdWNoIGN1c3RvbWVycyB1c3VhbGx5IHJlcXVp cmVzIHRoaXMga2luZCBvZiBhdHRyaWJ1dGVzIGZvciB0aGVpciBtYW5hZ2VtZW50IHB1cnBvc2Vz Lg0KDQpbREIyXQ0KDQpJIGRpZG4ndCByZWFsbHkgZm9sbG93IHRoaXMsIHNvcnJ5LiAgVGhlIG1v ZHVsZSBjb250YWlucyB0aGUNCg0KaW5mb3JtYXRpb24gdGhhdCBuZWVkcyB0byBiZSBzZW50IGZy b20gdGhlIGN1c3RvbWVyIHRvIHRoZSBTUCwgcmlnaHQ/DQoNCklmIHRoZSBjdXN0b21lciB1c2lu ZyB0aGUgbW9kZWwgKGkuZS4gdGhlIFRpZXIyIGluIHlvdXIgYWJvdmUgZXhhbXBsZSkNCg0KbmVl ZHMgdG8gdHJhY2sgd2hpY2ggb2YgdGhlaXIgb3duIGN1c3RvbWVycyB0aGUgc2VydmljZSBpcyBm b3IsIHRoYXQncw0KDQpzb21ldGhpbmcgdGhhdCdzIGludGVybmFsIHRvIHRoZW0sIGlzbid0IGl0 Pw0KDQpbS08zXSBZZXMsIHRoYXQncyBpbnRlcm5hbCB0byB0aGVtLCBidXQgdGhleSAoaS5lLiBv dXIgY3VzdG9tZXJzKSByZWFsbHkgcmVxdWVzdCBhbmQgYXJlIGN1cnJlbnRseSB1c2luZyB0aGlz LiBUaGVuLCB3ZSBuZWVkIHRvIG1vZGVsIHRoaXMuDQoNClBlcmhhcHMgSSBhbSBtaXN1bmRlcnN0 YW5kaW5nIHRoZSBzY2VuYXJpby4NCg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIGNh c2UgaXMgd2hlcmUgdGhlIHlhbmcgaXMgYmVpbmcgdXNlZCBiZXR3ZWVuIGEgVGllcjIgcHJvdmlk ZXIgKGxldHMgY2FsbCB0aGVtIFQyLXRlbGVjb20pIGFuZCBUaWVyMSBwcm92aWRlciAobGV0cyBj YWxsIHRoZW0gVDEtbmV0d29ya3MpLiAgSW4gb3RoZXIgd29yZHMsIGZyb20gdGhlIHBlcnNwZWN0 aXZlIG9mIHRoZSBSRkMgYW5kIHRoZSB5YW5nIG1vZHVsZSwgVDEtbmV0d29ya3MgaXMgdGhlIFNQ IGFuZCBUMi10ZWxlY29tIGlzIHRoZSBjdXN0b21lci4NCg0KVDItdGVsZWNvbSBoYXMgdGhlaXIg b3duIGN1c3RvbWVycyBjYWxsIHRoZW0gKGZvby1iYW5rLCBiYXItc3VwZXJtYXJrZXQgYW5kIGJh ei1hZHZlcnRpc2luZykuICBXaGVuZXZlciBUMi10ZWxlY29tIG9yZGVycyBhIG5ldyBWUE4gZnJv bSBUMS1uZXR3b3JrcywgdGhleSB3YW50IHRvIHJlY29yZCwgaW4gdGhlaXIgaW50ZXJuYWwgc3lz dGVtcywgd2hpY2ggb2YgdGhlaXIgZW5kIGN1c3RvbWVycyB0aGUgbmV3IFZQTiBpcyBmb3IuICBP ZiBjb3Vyc2UgdGhlcmUgaXMgcHJvYmFibHkgYSBsb3Qgb2Ygb3RoZXIgaW5mb3JtYXRpb24gdGhl eSB3YW50IHRvIHN0b3JlIGluIHRoZWlyIGludGVybmFsIHN5c3RlbXMgYWJvdXQgdGhlaXIgY3Vz dG9tZXJzLCBzdWNoIGFzIGNvbnRhY3QgaW5mbywgYmlsbGluZyBhbmQgaW52b2ljaW5nIGluZm8s IHRyb3VibGUgdGlja2V0cywgZXRjLg0KDQpXaGF0IEkgZG9uJ3QgdW5kZXJzdGFuZCBpcyB3aHkg VDItdGVsZWNvbSB3b3VsZCB3YW50IHRvIHNlbmQgdGhlIG5hbWUgb2YgdGhlaXIgZW5kLWN1c3Rv bWVyIChmb28tYmFuaywgYmFyLXN1cGVybWFya2V0IG9yIGJhei1hZHZlcnRpc2luZykgdG8gVDEt bmV0d29ya3MgYXMgcGFydCBvZiB0aGUgbmV0Y29uZiByZXF1ZXN0IHdoZW4gdGhleSBvcmRlciBh IG5ldyBWUE4uICBXaGF0IGlzIFQxLW5ldHdvcmtzIGdvaW5nIHRvIGRvIHdpdGggdGhpcyBpbmZv cm1hdGlvbj8NCg0KW1Fpbl06DQoxLldpdGggY3VzdG9tZXIgbmFtZSx5b3UgY291bGQgdXNlIGl0 IGFzIGEga2V5IHRvIGxvb2t1cCBkZXRhaWxlZCBjdXN0b21lciBpbmZvcm1hdGlvbiBzdWNoIGFz IGNvbnRhY3QgaW5mbywgYmlsbGluZyBpbmZvIGlmIG5lZWRlZC4NCjIuIFlvdSBmb3JnZXQgdGhh dCBWUE4gc2VydmljZSBpcyBkZWZpbmVkIGFzIGEgbGlzdCBvZiBWUE4gU2VydmljZS4gVGhhdCBp cyB0byBzYXkgZGlmZmVyZW50IFZQTiBzZXJ2aWNlIGNvdWxkIGJlbG9uZyB0byBkaWZmZXJlbnQg Y3VzdG9tZXIsDQpBZGRpbmcgY3VzdG9tZXIgbmFtZSwgd2UgY291bGQga25vdyB3aGljaCBjdXN0 b21lciBoYXMgd2hpY2ggVlBOIHNlcnZpY2UuDQozLiBjdXN0b21lciBuYW1lIGlzIGp1c3QgZGVm aW5lZCBhcyBhbiBvcHRpb25hbCBwYXJhbWV0ZXIuIFlvdSBkb27igJl0IG5lZWQgdG8gc3BlY2lm eSBpdCBpbiB0aGUgY2FzZSB5b3UgZG9u4oCZdCBuZWVkIGl0Lg0KICAgIERhdmlkDQoNCg0KDQot LQ0KDQpEYXZpZCBCYWxsDQoNCjxkYXZpYmFsbEBjaXNjby5jb20+PG1haWx0bzpkYXZpYmFsbEBj aXNjby5jb20+DQo= --_000_B8F9A780D330094D99AF023C5877DABA9A987485nkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN Cgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmi hOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i d2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRhdmlkOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QSBmZXcgdGhvdWdodHMgYW5kIGNvbW1l bnRzIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjp3aW5kb3d0ZXh0Ij4gRGF2aWQgQmFsbCBbbWFpbHRvOmRhdmliYWxsQGNpc2NvLmNv bV0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3 aW5kb3d0ZXh0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5k b3d0ZXh0Ij4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3 aW5kb3d0ZXh0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Njwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJF Ti1VUyI+Mjc8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDE5OjUzPGJyPg0KPC9zcGFu PjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IE9nYWtpLCBLZW5pY2hpOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgUWlu IFd1OyBsM3NtQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbTDNzbV0gTmV4dCBTdGVwIG9m IFJGQzgwNDk8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIEtlbmljaGkgLSB0aGVyZSBp cyBvbmUgb2YgeW91ciBhbnN3ZXJzIHRoYXQgSSdtIHN0aWxsIGNvbmZ1c2VkIGFib3V0LCBzZWUg YmVsb3c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gMjYvMDYvMjAxNyAwNDoyMywgT2dh a2ksIEtlbmljaGkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj40LiZuYnNwOyZuYnNwOyBVbmRlciB0aGUgVlBOIHNlcnZp Y2UsIHRoZXJlIGlzIGEgbGVhZiBmb3IgdGhlIGN1c3RvbWVyIG5hbWUuJm5ic3A7IElmIHRoZSBt b2RlbCBpcyBzdXBwb3NlZCB0byByZXByZXNlbnQgdGhlIHJlcXVlc3QgZnJvbSBhIGN1c3RvbWVy IHRvIHRoZSBTUCwgSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhlIGN1c3RvbWVyIG5hbWUgd291bGQg YmUga25vd24gb3V0LW9mLWJhbmQsIGUuZy4gZnJvbSB0aGUgQUFBIGZvciB0aGUgcmVxdWVzdD8m bmJzcDsgSXQgd291bGQgYmUgYmFkIGlmIG9uZSBjdXN0b21lciBjb3VsZCByZXF1ZXN0IHRoaW5n cyBmb3IgYW5vdGhlciBjdXN0b21lciBieSBmaWxsaW5nIGluIGEgZGlmZmVyZW50IGN1c3RvbWVy IG5hbWUgaW4gdGhlIG1vZGVsITxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtLT10gQSBjdXN0 b21lciBjYW4gb25seSBhY2Nlc3MgdGhlIG1vZGVsIGluc3RhbmNlIG9mIHRoYXQgY3VzdG9tZXIu IFBsZWFzZSBzZWUgc2VjdGlvbiAxMC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5bREJdIFllcyBleGFjdGx5IC0gaWYgYSBjdXN0b21lciBjYW4gb25seSBh Y2Nlc3MgdGhlaXIgb3duIGluc3RhbmNlIG9mIHRoZSBtb2RlbCwgd2h5IGRvZXMgdGhlIGN1c3Rv bWVyIG5hbWUgbmVlZCB0byBiZSBzcGVjaWZpZWQgd2l0aGluIHRoZSBtb2RlbD8mbmJzcDsgWW91 IGFscmVhZHkga25vdyB5b3UgYXJlIGRlYWxpbmcgd2l0aCB0aGF0IGN1c3RvbWVyJ3MgaW5zdGFu Y2Ugb2YgdGhlIG1vZGVsLiZuYnNwOyBJdCBzZWVtcyBsaWtlIHRoZSBjdXN0b21lci1uYW1lIGxl YWYgaXMgdW5uZWNlc3Nhcnk/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPltLT10gQXMgY29tbW9uIHVzZWNhc2VzLCBhIFZQTiBzZXJ2aWNlIGlzIHByb3Zp ZGVkIG5vdCBvbmx5IGJ5IFRpZXIgMSBwcm92aWRlcnMsIGJ1dCBhbHNvIGJ5IFRpZXIgMiBwcm92 aWRlcnMgb3IgSVQgZGl2aXNpb25zIG9mIGVudGVycHJpc2VzIGluIG9yZGVyIHRvIHByb3ZpZGUg dGhlaXIgb3duIGVuZCB1c2VycyBieSB1c2luZyBhIFRpZXIgMSBwcm92aWRlcidzIFZQTiBzZXJ2 aWNlLiBTdWNoIGN1c3RvbWVycyB1c3VhbGx5IHJlcXVpcmVzIHRoaXMga2luZCBvZiBhdHRyaWJ1 dGVzIGZvciB0aGVpciBtYW5hZ2VtZW50IHB1cnBvc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+W0RCMl08bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZGlkbid0IHJlYWxseSBm b2xsb3cgdGhpcywgc29ycnkuJm5ic3A7IFRoZSBtb2R1bGUgY29udGFpbnMgdGhlIDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+aW5mb3JtYXRpb24gdGhh dCBuZWVkcyB0byBiZSBzZW50IGZyb20gdGhlIGN1c3RvbWVyIHRvIHRoZSBTUCwgcmlnaHQ/Jm5i c3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+SWYg dGhlIGN1c3RvbWVyIHVzaW5nIHRoZSBtb2RlbCAoaS5lLiB0aGUgVGllcjIgaW4geW91ciBhYm92 ZSBleGFtcGxlKSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPm5lZWRzIHRvIHRyYWNrIHdoaWNoIG9mIHRoZWlyIG93biBjdXN0b21lcnMgdGhlIHNlcnZp Y2UgaXMgZm9yLCB0aGF0J3MgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5zb21ldGhpbmcgdGhhdCdzIGludGVybmFsIHRvIHRoZW0sIGlzbid0IGl0Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+W0tPM10gWWVzLCB0aGF0J3MgaW50ZXJuYWwgdG8gdGhlbSwgYnV0IHRoZXkgKGkuZS4g b3VyIGN1c3RvbWVycykgcmVhbGx5IHJlcXVlc3QgYW5kIGFyZSBjdXJyZW50bHkgdXNpbmcgdGhp cy4gVGhlbiwgd2UgbmVlZCB0byBtb2RlbCB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxi cj4NClBlcmhhcHMgSSBhbSBtaXN1bmRlcnN0YW5kaW5nIHRoZSBzY2VuYXJpby48YnI+DQo8YnI+ DQpJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0aGUgY2FzZSBpcyB3aGVyZSB0aGUgeWFuZyBp cyBiZWluZyB1c2VkIGJldHdlZW4gYSBUaWVyMiBwcm92aWRlciAobGV0cyBjYWxsIHRoZW0gVDIt dGVsZWNvbSkgYW5kIFRpZXIxIHByb3ZpZGVyIChsZXRzIGNhbGwgdGhlbSBUMS1uZXR3b3Jrcyku Jm5ic3A7IEluIG90aGVyIHdvcmRzLCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgUkZDIGFu ZCB0aGUgeWFuZyBtb2R1bGUsIFQxLW5ldHdvcmtzIGlzIHRoZQ0KIFNQIGFuZCBUMi10ZWxlY29t IGlzIHRoZSBjdXN0b21lci48YnI+DQo8YnI+DQpUMi10ZWxlY29tIGhhcyB0aGVpciBvd24gY3Vz dG9tZXJzIGNhbGwgdGhlbSAoZm9vLWJhbmssIGJhci1zdXBlcm1hcmtldCBhbmQgYmF6LWFkdmVy dGlzaW5nKS4mbmJzcDsgV2hlbmV2ZXIgVDItdGVsZWNvbSBvcmRlcnMgYSBuZXcgVlBOIGZyb20g VDEtbmV0d29ya3MsIHRoZXkgd2FudCB0byByZWNvcmQsIGluIHRoZWlyIGludGVybmFsIHN5c3Rl bXMsIHdoaWNoIG9mIHRoZWlyIGVuZCBjdXN0b21lcnMgdGhlIG5ldyBWUE4gaXMgZm9yLiZuYnNw OyBPZiBjb3Vyc2UNCiB0aGVyZSBpcyBwcm9iYWJseSBhIGxvdCBvZiBvdGhlciBpbmZvcm1hdGlv biB0aGV5IHdhbnQgdG8gc3RvcmUgaW4gdGhlaXIgaW50ZXJuYWwgc3lzdGVtcyBhYm91dCB0aGVp ciBjdXN0b21lcnMsIHN1Y2ggYXMgY29udGFjdCBpbmZvLCBiaWxsaW5nIGFuZCBpbnZvaWNpbmcg aW5mbywgdHJvdWJsZSB0aWNrZXRzLCBldGMuPGJyPg0KPGJyPg0KV2hhdCBJIGRvbid0IHVuZGVy c3RhbmQgaXMgd2h5IFQyLXRlbGVjb20gd291bGQgd2FudCB0byBzZW5kIHRoZSBuYW1lIG9mIHRo ZWlyIGVuZC1jdXN0b21lciAoZm9vLWJhbmssIGJhci1zdXBlcm1hcmtldCBvciBiYXotYWR2ZXJ0 aXNpbmcpIHRvIFQxLW5ldHdvcmtzIGFzIHBhcnQgb2YgdGhlIG5ldGNvbmYgcmVxdWVzdCB3aGVu IHRoZXkgb3JkZXIgYSBuZXcgVlBOLiZuYnNwOyBXaGF0IGlzIFQxLW5ldHdvcmtzIGdvaW5nIHRv IGRvIHdpdGggdGhpcyBpbmZvcm1hdGlvbj88YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bUWluXTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjEuV2l0aCBjdXN0b21lciBuYW1lLHlvdSBjb3VsZCB1c2UgaXQgYXMgYSBrZXkgdG8g bG9va3VwIGRldGFpbGVkIGN1c3RvbWVyIGluZm9ybWF0aW9uIHN1Y2ggYXMgY29udGFjdCBpbmZv LCBiaWxsaW5nIGluZm8gaWYgbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Mi4g WW91IGZvcmdldCB0aGF0IFZQTiBzZXJ2aWNlIGlzIGRlZmluZWQgYXMgYSBsaXN0IG9mIFZQTiBT ZXJ2aWNlLiBUaGF0IGlzIHRvIHNheSBkaWZmZXJlbnQgVlBOIHNlcnZpY2UgY291bGQgYmVsb25n IHRvIGRpZmZlcmVudCBjdXN0b21lciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFkZGlu ZyBjdXN0b21lciBuYW1lLCB3ZSBjb3VsZCBrbm93IHdoaWNoIGN1c3RvbWVyIGhhcyB3aGljaCBW UE4gc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjMuIGN1c3RvbWVyIG5hbWUg aXMganVzdCBkZWZpbmVkIGFzIGFuIG9wdGlvbmFsIHBhcmFtZXRlci4gWW91IGRvbuKAmXQgbmVl ZCB0byBzcGVjaWZ5IGl0IGluIHRoZSBjYXNlIHlvdSBkb27igJl0IG5lZWQgaXQuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgRGF2aWQ8YnI+DQo8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4t LSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkRhdmlk IEJhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxh IGhyZWY9Im1haWx0bzpkYXZpYmFsbEBjaXNjby5jb20iPiZsdDtkYXZpYmFsbEBjaXNjby5jb20m Z3Q7PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_B8F9A780D330094D99AF023C5877DABA9A987485nkgeml513mbxchi_-- From nobody Wed Jun 28 02:36:21 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A4612EC03 for ; Wed, 28 Jun 2017 02:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.492 X-Spam-Level: X-Spam-Status: No, score=-14.492 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIso1kvoTA3Z for ; Wed, 28 Jun 2017 02:36:15 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F36A126D85 for ; Wed, 28 Jun 2017 02:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16365; q=dns/txt; s=iport; t=1498642575; x=1499852175; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=/HsYhbigdsw0LMb6D7Orjc2HiFBSpx/7c4o4PyKHJXc=; b=fac7KI+tAOZu/N3ibwJEhgVCx1SsCTrWGsklRWY4RXxctd+PN25eJAc8 IaqtvUf3cP2QXRj7VD/XyIsve1Hjk6hf+WYQ8QdqMt5XBgaf2RjFM5N0e 5qFZZ4VlkXWdAUffOBw07jD1/8zvCU//3MdLQDa2FsH9HFpFUzwuXa/5A M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AAAVeFNZ/xbLJq1GFhoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJvglqDbIoZc5B1kE+FK4IRhhwCg0QYAQIBAQEBAQEBayiFGAEBAQE?= =?us-ascii?q?CASMKXAkCDgoTFAMCAkYRBgEMBgIBAYokCJMjnWKCJimLNAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2DJ4NMggyCeYE8gnUpRoJdgmEFkEWOL4p7iHWCCoVKg0uGd4x?= =?us-ascii?q?XiFEfOIEKMCEIGxVJhRYHEIFnPzaJOgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,274,1496102400"; d="scan'208,217";a="695453340" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2017 09:36:10 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5S9aAfC010396; Wed, 28 Jun 2017 09:36:10 GMT To: Qin Wu , "Ogaki, Kenichi" , "stephane.litkowski@orange.com" , "l3sm@ietf.org" References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> <00b101d2ee2b$8ef28ab0$acd7a010$@kddi.com> <0ed5e7de-9ab3-19a9-06ba-f0ec8a83c658@cisco.com> From: David Ball Message-ID: Date: Wed, 28 Jun 2017 10:36:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------015D108C68CCBDDEAB55A0B4" Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 09:36:20 -0000 This is a multi-part message in MIME format. --------------015D108C68CCBDDEAB55A0B4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: > > A few thoughts and comments below. > > *å‘件人:*David Ball [mailto:daviball@cisco.com] > *å‘é€æ—¶é—´:*2017å¹´6月27æ—¥19:53 > *收件人:*Ogaki, Kenichi; stephane.litkowski@orange.com; Qin Wu; > l3sm@ietf.org > *主题:*Re: [L3sm] Next Step of RFC8049 > > Thanks Kenichi - there is one of your answers that I'm still confused > about, see below: > > On 26/06/2017 04:23, Ogaki, Kenichi wrote: > > 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. > > [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] > > 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. > > > 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? > > [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 > -- David Ball --------------015D108C68CCBDDEAB55A0B4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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:

A few thoughts and comments below.

å‘件人: David Ball [mailto:daviball@cisco.com]
å‘é€æ—¶é—´: 2017å¹´6月27æ—¥ 19:53
收件人: Ogaki, Kenichi; stephane.litkowski@orange.com; Qin Wu; l3sm@ietf.org
主题: Re: [L3sm] Next Step of RFC8049

 

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

 

On 26/06/2017 04:23, Ogaki, Kenichi wrote:

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


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?

[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
<daviball@cisco.com>

-- 
David Ball
<daviball@cisco.com>
--------------015D108C68CCBDDEAB55A0B4-- From nobody Wed Jun 28 04:30:27 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D678812EC0B for ; Wed, 28 Jun 2017 04:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5-6XqXIAdEC for ; Wed, 28 Jun 2017 04:30:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA5F12EC12 for ; Wed, 28 Jun 2017 04:30:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPZ14018; Wed, 28 Jun 2017 11:30:19 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 28 Jun 2017 12:30:18 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 28 Jun 2017 19:30:10 +0800 From: Qin Wu To: "ke-oogaki@kddi.com" , "stephane.litkowski" , l3sm , daviball Thread-Topic: [L3sm] Next Step of RFC8049 Thread-Index: AQHS8AHmr+/QB9MzcEy31t2H4MnsWQ== Date: Wed, 28 Jun 2017 11:30:10 +0000 Message-ID: References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> <00b101d2ee2b$8ef28ab0$acd7a010$@kddi.com> <0ed5e7de-9ab3-19a9-06ba-f0ec8a83c658@cisco.com> , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_etPan595393426b8b456735aQinWudeiPhone_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5953934C.003C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ce0fda6ac40132574a0325c6d6ee8c80 Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 11:30:25 -0000 --_000_etPan595393426b8b456735aQinWudeiPhone_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U29ydCBvZiw6LSksaG93IGFib3V0IGFkZCBhIGZldyB0ZXh0cyBpbiBzZWN1cml0eSBzZWN0aW9u IHRvIGRpc2N1c3Mgc2VjdXJpdHkgcmlzayBvZiBkaXNjbG9zaW5nIGN1c3RvbWVyIG5hbWUsIGhv cGUgdGhpcyB3aWxsIGFkZHJlc3MgeW91ciBjb21tZW50IC4gVGhhbmtzIQ0KDQpTZW50IGZyb20g SFVBV0VJIEFueU9mZmljZQ0Kt6K8/sjLo7ogZGF2aWJhbGwNCsrVvP7Iy6O6IFFpbiBXdTsgT2dh a2ksIEtlbmljaGk7IHN0ZXBoYW5lLmxpdGtvd3NraTsgbDNzbTsNCtb3zOKjuiBSZTogW0wzc21d IE5leHQgU3RlcCBvZiBSRkM4MDQ5DQrKsbzko7ogMjAxNy0wNi0yOCAxNzozNjozMA0KDQoNCkhp IFFpbiwNCg0KWW91IGhhdmUgY3ljbGVkIHRoaXMgcm91bmQgdG8gdGhlIHN0YXJ0IG9mIHRoZSB0 aHJlYWQuIDopICBUaGVyZSBtdXN0IGJlIHNvbWUgb3V0LW9mLWJhbmQgd2F5IG9mIGlkZW50aWZ5 aW5nIGFuZCBhdXRoZW50aWNhdGluZyB0aGUgY3VzdG9tZXIgZnJvbSB3aG9tIHRoZSByZXF1ZXN0 IGlzIGJlaW5nIHJlY2VpdmVkLCBvdGhlcndpc2UgY3VzdG9tZXIgZm9vIGNvdWxkIHJlcXVlc3Qg YSBzZXJ2aWNlIGZvciBjdXN0b21lciBiYXIganVzdCBieSBmaWxsaW5nIGluIGEgZGlmZmVyZW50 IHZhbHVlIGZvciB0aGlzIGxlYWYgaW4gdGhlIG1vZGVsISAgWW91IGFyZSByaWdodCB0aGF0IHRo ZSBWUE4gc2VydmljZSBpcyBhIGxpc3QsIGJ1dCBhIGdpdmVuIGN1c3RvbWVyIHNob3VsZCBvbmx5 IGV2ZXIgYmUgYWJsZSB0byB1c2UgdGhlIG1vZGVsIHRvIGFjY2VzcyB0aGVpciBvd24gc2Vydmlj ZXMsIHRoZXkgc2hvdWxkIG5vdCBiZSBhYmxlIHRvIGFjY2VzcyBzZXJ2aWNlcyBmb3IgYW55IG90 aGVyIGN1c3RvbWVyLg0KDQogICAgRGF2aWQNCg0KT24gMjgvMDYvMjAxNyAwMzozNywgUWluIFd1 IHdyb3RlOg0KRGF2aWQ6DQpBIGZldyB0aG91Z2h0cyBhbmQgY29tbWVudHMgYmVsb3cuDQq3orz+ yMs6IERhdmlkIEJhbGwgW21haWx0bzpkYXZpYmFsbEBjaXNjby5jb21dDQq3osvNyrG85DogMjAx N8TqNtTCMjfI1SAxOTo1Mw0KytW8/sjLOiBPZ2FraSwgS2VuaWNoaTsgc3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPjsgUWlu IFd1OyBsM3NtQGlldGYub3JnPG1haWx0bzpsM3NtQGlldGYub3JnPg0K1vfM4jogUmU6IFtMM3Nt XSBOZXh0IFN0ZXAgb2YgUkZDODA0OQ0KDQoNClRoYW5rcyBLZW5pY2hpIC0gdGhlcmUgaXMgb25l IG9mIHlvdXIgYW5zd2VycyB0aGF0IEknbSBzdGlsbCBjb25mdXNlZCBhYm91dCwgc2VlIGJlbG93 Og0KDQpPbiAyNi8wNi8yMDE3IDA0OjIzLCBPZ2FraSwgS2VuaWNoaSB3cm90ZToNCg0KNC4gICBV bmRlciB0aGUgVlBOIHNlcnZpY2UsIHRoZXJlIGlzIGEgbGVhZiBmb3IgdGhlIGN1c3RvbWVyIG5h bWUuICBJZiB0aGUgbW9kZWwgaXMgc3VwcG9zZWQgdG8gcmVwcmVzZW50IHRoZSByZXF1ZXN0IGZy b20gYSBjdXN0b21lciB0byB0aGUgU1AsIEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoZSBjdXN0b21l ciBuYW1lIHdvdWxkIGJlIGtub3duIG91dC1vZi1iYW5kLCBlLmcuIGZyb20gdGhlIEFBQSBmb3Ig dGhlIHJlcXVlc3Q/ICBJdCB3b3VsZCBiZSBiYWQgaWYgb25lIGN1c3RvbWVyIGNvdWxkIHJlcXVl c3QgdGhpbmdzIGZvciBhbm90aGVyIGN1c3RvbWVyIGJ5IGZpbGxpbmcgaW4gYSBkaWZmZXJlbnQg Y3VzdG9tZXIgbmFtZSBpbiB0aGUgbW9kZWwhDQoNCg0KDQogICAgIFtLT10gQSBjdXN0b21lciBj YW4gb25seSBhY2Nlc3MgdGhlIG1vZGVsIGluc3RhbmNlIG9mIHRoYXQgY3VzdG9tZXIuIFBsZWFz ZSBzZWUgc2VjdGlvbiAxMC4NCg0KDQoNCg0KDQpbREJdIFllcyBleGFjdGx5IC0gaWYgYSBjdXN0 b21lciBjYW4gb25seSBhY2Nlc3MgdGhlaXIgb3duIGluc3RhbmNlIG9mIHRoZSBtb2RlbCwgd2h5 IGRvZXMgdGhlIGN1c3RvbWVyIG5hbWUgbmVlZCB0byBiZSBzcGVjaWZpZWQgd2l0aGluIHRoZSBt b2RlbD8gIFlvdSBhbHJlYWR5IGtub3cgeW91IGFyZSBkZWFsaW5nIHdpdGggdGhhdCBjdXN0b21l cidzIGluc3RhbmNlIG9mIHRoZSBtb2RlbC4gIEl0IHNlZW1zIGxpa2UgdGhlIGN1c3RvbWVyLW5h bWUgbGVhZiBpcyB1bm5lY2Vzc2FyeT8NCg0KDQoNCltLT10gQXMgY29tbW9uIHVzZWNhc2VzLCBh IFZQTiBzZXJ2aWNlIGlzIHByb3ZpZGVkIG5vdCBvbmx5IGJ5IFRpZXIgMSBwcm92aWRlcnMsIGJ1 dCBhbHNvIGJ5IFRpZXIgMiBwcm92aWRlcnMgb3IgSVQgZGl2aXNpb25zIG9mIGVudGVycHJpc2Vz IGluIG9yZGVyIHRvIHByb3ZpZGUgdGhlaXIgb3duIGVuZCB1c2VycyBieSB1c2luZyBhIFRpZXIg MSBwcm92aWRlcidzIFZQTiBzZXJ2aWNlLiBTdWNoIGN1c3RvbWVycyB1c3VhbGx5IHJlcXVpcmVz IHRoaXMga2luZCBvZiBhdHRyaWJ1dGVzIGZvciB0aGVpciBtYW5hZ2VtZW50IHB1cnBvc2VzLg0K DQpbREIyXQ0KDQpJIGRpZG4ndCByZWFsbHkgZm9sbG93IHRoaXMsIHNvcnJ5LiAgVGhlIG1vZHVs ZSBjb250YWlucyB0aGUNCg0KaW5mb3JtYXRpb24gdGhhdCBuZWVkcyB0byBiZSBzZW50IGZyb20g dGhlIGN1c3RvbWVyIHRvIHRoZSBTUCwgcmlnaHQ/DQoNCklmIHRoZSBjdXN0b21lciB1c2luZyB0 aGUgbW9kZWwgKGkuZS4gdGhlIFRpZXIyIGluIHlvdXIgYWJvdmUgZXhhbXBsZSkNCg0KbmVlZHMg dG8gdHJhY2sgd2hpY2ggb2YgdGhlaXIgb3duIGN1c3RvbWVycyB0aGUgc2VydmljZSBpcyBmb3Is IHRoYXQncw0KDQpzb21ldGhpbmcgdGhhdCdzIGludGVybmFsIHRvIHRoZW0sIGlzbid0IGl0Pw0K DQpbS08zXSBZZXMsIHRoYXQncyBpbnRlcm5hbCB0byB0aGVtLCBidXQgdGhleSAoaS5lLiBvdXIg Y3VzdG9tZXJzKSByZWFsbHkgcmVxdWVzdCBhbmQgYXJlIGN1cnJlbnRseSB1c2luZyB0aGlzLiBU aGVuLCB3ZSBuZWVkIHRvIG1vZGVsIHRoaXMuDQoNClBlcmhhcHMgSSBhbSBtaXN1bmRlcnN0YW5k aW5nIHRoZSBzY2VuYXJpby4NCg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIGNhc2Ug aXMgd2hlcmUgdGhlIHlhbmcgaXMgYmVpbmcgdXNlZCBiZXR3ZWVuIGEgVGllcjIgcHJvdmlkZXIg KGxldHMgY2FsbCB0aGVtIFQyLXRlbGVjb20pIGFuZCBUaWVyMSBwcm92aWRlciAobGV0cyBjYWxs IHRoZW0gVDEtbmV0d29ya3MpLiAgSW4gb3RoZXIgd29yZHMsIGZyb20gdGhlIHBlcnNwZWN0aXZl IG9mIHRoZSBSRkMgYW5kIHRoZSB5YW5nIG1vZHVsZSwgVDEtbmV0d29ya3MgaXMgdGhlIFNQIGFu ZCBUMi10ZWxlY29tIGlzIHRoZSBjdXN0b21lci4NCg0KVDItdGVsZWNvbSBoYXMgdGhlaXIgb3du IGN1c3RvbWVycyBjYWxsIHRoZW0gKGZvby1iYW5rLCBiYXItc3VwZXJtYXJrZXQgYW5kIGJhei1h ZHZlcnRpc2luZykuICBXaGVuZXZlciBUMi10ZWxlY29tIG9yZGVycyBhIG5ldyBWUE4gZnJvbSBU MS1uZXR3b3JrcywgdGhleSB3YW50IHRvIHJlY29yZCwgaW4gdGhlaXIgaW50ZXJuYWwgc3lzdGVt cywgd2hpY2ggb2YgdGhlaXIgZW5kIGN1c3RvbWVycyB0aGUgbmV3IFZQTiBpcyBmb3IuICBPZiBj b3Vyc2UgdGhlcmUgaXMgcHJvYmFibHkgYSBsb3Qgb2Ygb3RoZXIgaW5mb3JtYXRpb24gdGhleSB3 YW50IHRvIHN0b3JlIGluIHRoZWlyIGludGVybmFsIHN5c3RlbXMgYWJvdXQgdGhlaXIgY3VzdG9t ZXJzLCBzdWNoIGFzIGNvbnRhY3QgaW5mbywgYmlsbGluZyBhbmQgaW52b2ljaW5nIGluZm8sIHRy b3VibGUgdGlja2V0cywgZXRjLg0KDQpXaGF0IEkgZG9uJ3QgdW5kZXJzdGFuZCBpcyB3aHkgVDIt dGVsZWNvbSB3b3VsZCB3YW50IHRvIHNlbmQgdGhlIG5hbWUgb2YgdGhlaXIgZW5kLWN1c3RvbWVy IChmb28tYmFuaywgYmFyLXN1cGVybWFya2V0IG9yIGJhei1hZHZlcnRpc2luZykgdG8gVDEtbmV0 d29ya3MgYXMgcGFydCBvZiB0aGUgbmV0Y29uZiByZXF1ZXN0IHdoZW4gdGhleSBvcmRlciBhIG5l dyBWUE4uICBXaGF0IGlzIFQxLW5ldHdvcmtzIGdvaW5nIHRvIGRvIHdpdGggdGhpcyBpbmZvcm1h dGlvbj8NCg0KW1Fpbl06DQoxLldpdGggY3VzdG9tZXIgbmFtZSx5b3UgY291bGQgdXNlIGl0IGFz IGEga2V5IHRvIGxvb2t1cCBkZXRhaWxlZCBjdXN0b21lciBpbmZvcm1hdGlvbiBzdWNoIGFzIGNv bnRhY3QgaW5mbywgYmlsbGluZyBpbmZvIGlmIG5lZWRlZC4NCjIuIFlvdSBmb3JnZXQgdGhhdCBW UE4gc2VydmljZSBpcyBkZWZpbmVkIGFzIGEgbGlzdCBvZiBWUE4gU2VydmljZS4gVGhhdCBpcyB0 byBzYXkgZGlmZmVyZW50IFZQTiBzZXJ2aWNlIGNvdWxkIGJlbG9uZyB0byBkaWZmZXJlbnQgY3Vz dG9tZXIsDQpBZGRpbmcgY3VzdG9tZXIgbmFtZSwgd2UgY291bGQga25vdyB3aGljaCBjdXN0b21l ciBoYXMgd2hpY2ggVlBOIHNlcnZpY2UuDQozLiBjdXN0b21lciBuYW1lIGlzIGp1c3QgZGVmaW5l ZCBhcyBhbiBvcHRpb25hbCBwYXJhbWV0ZXIuIFlvdSBkb26hr3QgbmVlZCB0byBzcGVjaWZ5IGl0 IGluIHRoZSBjYXNlIHlvdSBkb26hr3QgbmVlZCBpdC4NCiAgICBEYXZpZA0KDQoNCg0KLS0NCg0K RGF2aWQgQmFsbA0KDQo8ZGF2aWJhbGxAY2lzY28uY29tPjxtYWlsdG86ZGF2aWJhbGxAY2lzY28u Y29tPg0KDQoNCi0tDQpEYXZpZCBCYWxsDQo8ZGF2aWJhbGxAY2lzY28uY29tPjxtYWlsdG86ZGF2 aWJhbGxAY2lzY28uY29tPg0K --_000_etPan595393426b8b456735aQinWudeiPhone_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Sort of,:-),how about add a few texts&nb= sp;in security section to discuss security ri= sk of disclosing customer name, hope this&nbs= p;will address your comment . Thanks!

Sent from HUAWEI AnyOffice
=B7=A2=BC=FE=C8=CB=A3=BA daviball
=CA=D5=BC=FE=C8=CB=A3=BA Qin Wu; Ogaki, Kenichi; stephane.litko= wski; l3sm;
=D6=F7=CC=E2=A3=BA Re: [L3sm] Next Step of RFC8049
=CA=B1=BC=E4=A3=BA 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 acc= ess services for any other customer.

    David

On 28/06/2017 03:37, Qin Wu wrote:

David:

A few th= oughts and comments below.

: David Ball [mailto:daviball@= cisco.com]
=B7=A2=CB=CD= =CA=B1=BC=E4: 2017=C4=EA6=D4=C227=C8=D5 19:53
=CA=D5=BC=FE=C8=CB: Ogaki, Kenichi; stephane.litkowski@orange.com; Qin Wu; l3sm@ietf.org
=D6=F7=CC=E2: Re: [L3sm] Next Step of RFC8049

 

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

 

On 26/06/2017 04:23, Ogaki, Ken= ichi wrote:

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 wou=
ld be bad if one customer could request things for another customer by fill=
ing in a different customer name in the model!
        &=
nbsp;    
     [KO] A customer can only=
 access the model instance of that customer. Please see section 10.<=
/pre>

 


 


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


 


[KO] As common usecases, a VPN service is provide=
d not only by Tier 1 providers, but also by Tier 2 providers or IT division=
s 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 attrib=
utes for their management purposes.


[DB2]
I didn't really follow this, sorry.  The mod=
ule contains the 
information that needs to be sent from the custom=
er to the SP, right?  
If the customer using the model (i.e. the Tier2 i=
n your above example) 
needs to track which of their own customers the s=
ervice 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.


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 a= nd 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-netwo= rks, they want to record, in their internal systems, which of their end cus= tomers the new VPN is for.  Of course there is probably a lot of other information they want to store in their i= nternal systems about their customers, such as contact info, billing and in= voicing info, trouble tickets, etc.

What I don't understand is why T2-telecom would want to send the name of th= eir end-customer (foo-bank, bar-supermarket or baz-advertising) to T1-netwo= rks 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 informa= tion 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. cust= omer name is just defined as an optional parameter. You don=A1=AFt need to = specify it in the case you don=A1=AFt need it.<= br>     David


-- 
David Ball
<davibal=
l@cisco.com>

--=20
David Ball
<d=
aviball@cisco.com>
--_000_etPan595393426b8b456735aQinWudeiPhone_-- From nobody Wed Jun 28 04:53:13 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B480F1205F0 for ; Wed, 28 Jun 2017 04:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jozwiw2I-KAe for ; Wed, 28 Jun 2017 04:53:10 -0700 (PDT) Received: from post-send.kddi.com (athena4.kddi.com [27.90.165.197]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEF31204DA for ; Wed, 28 Jun 2017 04:53:09 -0700 (PDT) Received: from LTMC2122.kddi.com (LTMC2122.kddi.com [10.206.0.63]) by post-send.kddi.com (KDDI Mail) with ESMTP id 228D7120036; Wed, 28 Jun 2017 20:53:08 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2122.kddi.com with ESMTP; Wed, 28 Jun 2017 20:53:08 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id E66FA4C005A; Wed, 28 Jun 2017 20:53:07 +0900 (JST) Received: from LTMC2151.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id DB4924C0058; Wed, 28 Jun 2017 20:53:07 +0900 (JST) Received: from LTMC2151.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id v5SBr7Za003235; Wed, 28 Jun 2017 20:53:07 +0900 Received: from LTMC2151.kddi.com.mid_22649676 (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id v5SBh57D048547; Wed, 28 Jun 2017 20:43:05 +0900 X-SA-MID: 22649676 Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Wed, 28 Jun 2017 20:43:04 +0900 From: "Ogaki, Kenichi" To: "'David Ball'" , , "'Qin Wu'" , References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> <00b101d2ee2b$8ef28ab0$acd7a010$@kddi.com> <0ed5e7de-9ab3-19a9-06ba-f0ec8a83c658@cisco.com> In-Reply-To: <0ed5e7de-9ab3-19a9-06ba-f0ec8a83c658@cisco.com> Date: Wed, 28 Jun 2017 20:43:04 +0900 Message-ID: <002a01d2f003$b45408e0$1cfc1aa0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI8KJ/JrK2KyxsjaGJAhXNMm3Sl2gG6ddmrAczEpsMBsDkrZAKEX+92AgfRRr0BCjGOgwFvVOKzAcQOH5kCc5eLO6DkD0lA Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 11:53:13 -0000 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:daviball@cisco.com] Sent: Tuesday, June 27, 2017 8:53 PM To: Ogaki, Kenichi; stephane.litkowski@orange.com; 'Qin Wu'; l3sm@ietf.org Subject: Re: [L3sm] Next Step of RFC8049 Thanks Kenichi - there is one of your answers that I'm still confused about, see below: On 26/06/2017 04:23, Ogaki, Kenichi wrote: 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. [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] 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. 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 From nobody Wed Jun 28 04:56:23 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC4C1205F0 for ; Wed, 28 Jun 2017 04:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA-RE13iJH0x for ; Wed, 28 Jun 2017 04:56:19 -0700 (PDT) Received: from post-send.kddi.com (athena4.kddi.com [27.90.165.197]) by ietfa.amsl.com (Postfix) with ESMTP id 74FEC1204DA for ; Wed, 28 Jun 2017 04:56:18 -0700 (PDT) Received: from LTMC2121.kddi.com (LTMC2121.kddi.com [10.206.0.61]) by post-send.kddi.com (KDDI Mail) with ESMTP id 0FCF1120020; Wed, 28 Jun 2017 20:56:18 +0900 (JST) Received: from LTMC2146.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2121.kddi.com with ESMTP; Wed, 28 Jun 2017 20:56:18 +0900 Received: from LTMC2146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id D3FE830005D; Wed, 28 Jun 2017 20:56:17 +0900 (JST) Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2146.kddi.com (Postfix) with ESMTP id C9099300051; Wed, 28 Jun 2017 20:56:17 +0900 (JST) Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id v5SBuH5E030243; Wed, 28 Jun 2017 20:56:17 +0900 Received: from LTMC2152.kddi.com.mid_22453559 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id v5SBkEqK026895; Wed, 28 Jun 2017 20:46:14 +0900 X-SA-MID: 22453559 Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Wed, 28 Jun 2017 20:46:14 +0900 From: "Ogaki, Kenichi" To: "'Qin Wu'" , "'stephane.litkowski'" , "'l3sm'" , "'daviball'" References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> <00b101d2ee2b$8ef28ab0$acd7a010$@kddi.com> <0ed5e7de-9ab3-19a9-06ba-f0ec8a83c658@cisco.com> , In-Reply-To: Date: Wed, 28 Jun 2017 20:46:14 +0900 Message-ID: <002b01d2f004$252ce3c0$6f86ab40$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI8KJ/JrK2KyxsjaGJAhXNMm3Sl2gG6ddmrAczEpsMBsDkrZAKEX+92AgfRRr0BCjGOgwFvVOKzAcQOH5kCc5eLOwDFi/E/AczrG9UCWAzZS6C8u4iA Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 11:56:21 -0000 Hi Qin, This is already covered by Section 10. And, I answered to David earlier. 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! =20 =09 [KO] A customer can only access the model instance of that customer. = Please see section 10. Thanks, Kenichi -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: Wednesday, June 28, 2017 8:30 PM To: ke-oogaki@kddi.com; stephane.litkowski; l3sm; daviball Subject: RE: [L3sm] Next Step of RFC8049 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 =B7=A2=BC=FE=C8=CB=A3=BA daviball =CA=D5=BC=FE=C8=CB=A3=BA Qin Wu; Ogaki, Kenichi; stephane.litkowski; = l3sm;=20 =D6=F7=CC=E2=A3=BA Re: [L3sm] Next Step of RFC8049 =CA=B1=BC=E4=A3=BA 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 On 28/06/2017 03:37, Qin Wu wrote: David: A few thoughts and comments below. =B7=A2=BC=FE=C8=CB: David Ball [mailto:daviball@cisco.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA6=D4=C227=C8=D5 19:53 =CA=D5=BC=FE=C8=CB: Ogaki, Kenichi; stephane.litkowski@orange.com = ; Qin Wu; l3sm@ietf.org = =20 =D6=F7=CC=E2: Re: [L3sm] Next Step of RFC8049 =20 Thanks Kenichi - there is one of your answers that I'm still confused = about, see below: =20 On 26/06/2017 04:23, Ogaki, Kenichi wrote: 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! =20 [KO] A customer can only access the model instance of that = customer. Please see section 10. =20 =20 [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? =20 [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] I didn't really follow this, sorry. The module contains the=20 information that needs to be sent from the customer to the SP, right? = =20 If the customer using the model (i.e. the Tier2 in your above = example)=20 needs to track which of their own customers the service is for, = that's=20 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. =09 Perhaps I am misunderstanding the scenario. =09 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. =09 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. =09 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? =09 [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=A1=AFt need to specify it in the case you don=A1=AFt need it. David =09 =09 =09 --=20 David Ball =20 --=20 David Ball =20 From nobody Wed Jun 28 05:00:50 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DBC1296C9 for ; Wed, 28 Jun 2017 05:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXjnGIgV7fPA for ; Wed, 28 Jun 2017 05:00:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1561296B3 for ; Wed, 28 Jun 2017 05:00:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJI50114; Wed, 28 Jun 2017 12:00:43 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 28 Jun 2017 13:00:41 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 28 Jun 2017 20:00:38 +0800 From: Qin Wu To: "stephane.litkowski" , l3sm , daviball , ke-oogaki Thread-Topic: [L3sm] Next Step of RFC8049 Thread-Index: AQHS8AYoUnEtPkNd1UuQtaHd1JhOiQ== Date: Wed, 28 Jun 2017 12:00:38 +0000 Message-ID: References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> <00b101d2ee2b$8ef28ab0$acd7a010$@kddi.com> <0ed5e7de-9ab3-19a9-06ba-f0ec8a83c658@cisco.com> , , <002b01d2f004$252ce3c0$6f86ab40$@kddi.com> In-Reply-To: <002b01d2f004$252ce3c0$6f86ab40$@kddi.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_etPan59539a656b8b4567363QinWudeiPhone_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59539A6B.031A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 40f7354350e0c9bd9d1721f22d2a0ad5 Archived-At: Subject: [L3sm] =?gb2312?b?tPC4tDogICBOZXh0IFN0ZXAgb2YgUkZDODA0OQ==?= X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 12:00:50 -0000 --_000_etPan59539a656b8b4567363QinWudeiPhone_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 V29vcHMsIEkgbWlzcyB0byBjaGVjayB0aGF0LiBUaGFuayBmb3IgY2xhcmlmaWNhdGlvbi4NCg0K LVFpbg0KU2VudCBmcm9tIEhVQVdFSSBBbnlPZmZpY2UNCreivP7Iy6O6IGtlLW9vZ2FraQ0KytW8 /sjLo7ogUWluIFd1OyBzdGVwaGFuZS5saXRrb3dza2k7IGwzc207IGRhdmliYWxsOw0K1vfM4qO6 IFJFOiBbTDNzbV0gTmV4dCBTdGVwIG9mIFJGQzgwNDkNCsqxvOSjuiAyMDE3LTA2LTI4IDE5OjU2 OjIzDQoNCg0KSGkgUWluLA0KDQpUaGlzIGlzIGFscmVhZHkgY292ZXJlZCBieSBTZWN0aW9uIDEw Lg0KDQpBbmQsIEkgYW5zd2VyZWQgdG8gRGF2aWQgZWFybGllci4NCg0KNC4gICAgICBVbmRlciB0 aGUgVlBOIHNlcnZpY2UsIHRoZXJlIGlzIGEgbGVhZiBmb3IgdGhlIGN1c3RvbWVyIG5hbWUuICBJ ZiB0aGUgbW9kZWwgaXMgc3VwcG9zZWQgdG8gcmVwcmVzZW50IHRoZSByZXF1ZXN0IGZyb20gYSBj dXN0b21lciB0byB0aGUgU1AsIEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoZSBjdXN0b21lciBuYW1l IHdvdWxkIGJlIGtub3duIG91dC1vZi1iYW5kLCBlLmcuIGZyb20gdGhlIEFBQSBmb3IgdGhlIHJl cXVlc3Q/ICBJdCB3b3VsZCBiZSBiYWQgaWYgb25lIGN1c3RvbWVyIGNvdWxkIHJlcXVlc3QgdGhp bmdzIGZvciBhbm90aGVyIGN1c3RvbWVyIGJ5IGZpbGxpbmcgaW4gYSBkaWZmZXJlbnQgY3VzdG9t ZXIgbmFtZSBpbiB0aGUgbW9kZWwhDQoNCltLT10gQSBjdXN0b21lciBjYW4gb25seSBhY2Nlc3Mg dGhlIG1vZGVsIGluc3RhbmNlIG9mIHRoYXQgY3VzdG9tZXIuIFBsZWFzZSBzZWUgc2VjdGlvbiAx MC4NCg0KVGhhbmtzLA0KS2VuaWNoaQ0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFFpbiBXdSBbbWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVu ZSAyOCwgMjAxNyA4OjMwIFBNDQpUbzoga2Utb29nYWtpQGtkZGkuY29tOyBzdGVwaGFuZS5saXRr b3dza2k7IGwzc207IGRhdmliYWxsDQpTdWJqZWN0OiBSRTogW0wzc21dIE5leHQgU3RlcCBvZiBS RkM4MDQ5DQoNClNvcnQgb2YsOi0pLGhvdyBhYm91dCBhZGQgYSBmZXcgdGV4dHMgaW4gc2VjdXJp dHkgc2VjdGlvbiB0byBkaXNjdXNzIHNlY3VyaXR5IHJpc2sgb2YgZGlzY2xvc2luZyBjdXN0b21l ciBuYW1lLCBob3BlIHRoaXMgd2lsbCBhZGRyZXNzIHlvdXIgY29tbWVudCAuIFRoYW5rcyENCg0K U2VudCBmcm9tIEhVQVdFSSBBbnlPZmZpY2UNCreivP7Iy6O6IGRhdmliYWxsDQrK1bz+yMujuiBR aW4gV3U7IE9nYWtpLCBLZW5pY2hpOyBzdGVwaGFuZS5saXRrb3dza2k7IGwzc207DQrW98zio7og UmU6IFtMM3NtXSBOZXh0IFN0ZXAgb2YgUkZDODA0OQ0KyrG85KO6IDIwMTctMDYtMjggMTc6MzY6 MzANCg0KDQpIaSBRaW4sDQoNCllvdSBoYXZlIGN5Y2xlZCB0aGlzIHJvdW5kIHRvIHRoZSBzdGFy dCBvZiB0aGUgdGhyZWFkLiA6KSAgVGhlcmUgbXVzdCBiZSBzb21lIG91dC1vZi1iYW5kIHdheSBv ZiBpZGVudGlmeWluZyBhbmQgYXV0aGVudGljYXRpbmcgdGhlIGN1c3RvbWVyIGZyb20gd2hvbSB0 aGUgcmVxdWVzdCBpcyBiZWluZyByZWNlaXZlZCwgb3RoZXJ3aXNlIGN1c3RvbWVyIGZvbyBjb3Vs ZCByZXF1ZXN0IGEgc2VydmljZSBmb3IgY3VzdG9tZXIgYmFyIGp1c3QgYnkgZmlsbGluZyBpbiBh IGRpZmZlcmVudCB2YWx1ZSBmb3IgdGhpcyBsZWFmIGluIHRoZSBtb2RlbCEgIFlvdSBhcmUgcmln aHQgdGhhdCB0aGUgVlBOIHNlcnZpY2UgaXMgYSBsaXN0LCBidXQgYSBnaXZlbiBjdXN0b21lciBz aG91bGQgb25seSBldmVyIGJlIGFibGUgdG8gdXNlIHRoZSBtb2RlbCB0byBhY2Nlc3MgdGhlaXIg b3duIHNlcnZpY2VzLCB0aGV5IHNob3VsZCBub3QgYmUgYWJsZSB0byBhY2Nlc3Mgc2VydmljZXMg Zm9yIGFueSBvdGhlciBjdXN0b21lci4NCg0KICAgIERhdmlkDQoNCg0KT24gMjgvMDYvMjAxNyAw MzozNywgUWluIFd1IHdyb3RlOg0KDQoNCiAgICAgICAgRGF2aWQ6DQoNCiAgICAgICAgQSBmZXcg dGhvdWdodHMgYW5kIGNvbW1lbnRzIGJlbG93Lg0KDQogICAgICAgILeivP7IyzogRGF2aWQgQmFs bCBbbWFpbHRvOmRhdmliYWxsQGNpc2NvLmNvbV0NCiAgICAgICAgt6LLzcqxvOQ6IDIwMTfE6jbU wjI3yNUgMTk6NTMNCiAgICAgICAgytW8/sjLOiBPZ2FraSwgS2VuaWNoaTsgc3RlcGhhbmUubGl0 a293c2tpQG9yYW5nZS5jb20gPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4g OyBRaW4gV3U7IGwzc21AaWV0Zi5vcmcgPG1haWx0bzpsM3NtQGlldGYub3JnPg0KICAgICAgICDW 98ziOiBSZTogW0wzc21dIE5leHQgU3RlcCBvZiBSRkM4MDQ5DQoNCg0KDQogICAgICAgIFRoYW5r cyBLZW5pY2hpIC0gdGhlcmUgaXMgb25lIG9mIHlvdXIgYW5zd2VycyB0aGF0IEknbSBzdGlsbCBj b25mdXNlZCBhYm91dCwgc2VlIGJlbG93Og0KDQoNCg0KICAgICAgICBPbiAyNi8wNi8yMDE3IDA0 OjIzLCBPZ2FraSwgS2VuaWNoaSB3cm90ZToNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA0LiAgIFVuZGVyIHRoZSBWUE4gc2VydmljZSwgdGhlcmUgaXMgYSBsZWFmIGZvciB0aGUg Y3VzdG9tZXIgbmFtZS4gIElmIHRoZSBtb2RlbCBpcyBzdXBwb3NlZCB0byByZXByZXNlbnQgdGhl IHJlcXVlc3QgZnJvbSBhIGN1c3RvbWVyIHRvIHRoZSBTUCwgSSB3b3VsZCBoYXZlIHRob3VnaHQg dGhlIGN1c3RvbWVyIG5hbWUgd291bGQgYmUga25vd24gb3V0LW9mLWJhbmQsIGUuZy4gZnJvbSB0 aGUgQUFBIGZvciB0aGUgcmVxdWVzdD8gIEl0IHdvdWxkIGJlIGJhZCBpZiBvbmUgY3VzdG9tZXIg Y291bGQgcmVxdWVzdCB0aGluZ3MgZm9yIGFub3RoZXIgY3VzdG9tZXIgYnkgZmlsbGluZyBpbiBh IGRpZmZlcmVudCBjdXN0b21lciBuYW1lIGluIHRoZSBtb2RlbCENCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtLT10gQSBjdXN0b21lciBjYW4gb25seSBhY2Nlc3MgdGhl IG1vZGVsIGluc3RhbmNlIG9mIHRoYXQgY3VzdG9tZXIuIFBsZWFzZSBzZWUgc2VjdGlvbiAxMC4N Cg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtEQl0gWWVzIGV4YWN0bHkgLSBp ZiBhIGN1c3RvbWVyIGNhbiBvbmx5IGFjY2VzcyB0aGVpciBvd24gaW5zdGFuY2Ugb2YgdGhlIG1v ZGVsLCB3aHkgZG9lcyB0aGUgY3VzdG9tZXIgbmFtZSBuZWVkIHRvIGJlIHNwZWNpZmllZCB3aXRo aW4gdGhlIG1vZGVsPyAgWW91IGFscmVhZHkga25vdyB5b3UgYXJlIGRlYWxpbmcgd2l0aCB0aGF0 IGN1c3RvbWVyJ3MgaW5zdGFuY2Ugb2YgdGhlIG1vZGVsLiAgSXQgc2VlbXMgbGlrZSB0aGUgY3Vz dG9tZXItbmFtZSBsZWFmIGlzIHVubmVjZXNzYXJ5Pw0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtLT10gQXMgY29tbW9uIHVzZWNhc2VzLCBhIFZQTiBzZXJ2aWNlIGlzIHByb3Zp ZGVkIG5vdCBvbmx5IGJ5IFRpZXIgMSBwcm92aWRlcnMsIGJ1dCBhbHNvIGJ5IFRpZXIgMiBwcm92 aWRlcnMgb3IgSVQgZGl2aXNpb25zIG9mIGVudGVycHJpc2VzIGluIG9yZGVyIHRvIHByb3ZpZGUg dGhlaXIgb3duIGVuZCB1c2VycyBieSB1c2luZyBhIFRpZXIgMSBwcm92aWRlcidzIFZQTiBzZXJ2 aWNlLiBTdWNoIGN1c3RvbWVycyB1c3VhbGx5IHJlcXVpcmVzIHRoaXMga2luZCBvZiBhdHRyaWJ1 dGVzIGZvciB0aGVpciBtYW5hZ2VtZW50IHB1cnBvc2VzLg0KDQogICAgICAgICAgICAgICAgICAg ICAgICBbREIyXQ0KICAgICAgICAgICAgICAgICAgICAgICAgSSBkaWRuJ3QgcmVhbGx5IGZvbGxv dyB0aGlzLCBzb3JyeS4gIFRoZSBtb2R1bGUgY29udGFpbnMgdGhlDQogICAgICAgICAgICAgICAg ICAgICAgICBpbmZvcm1hdGlvbiB0aGF0IG5lZWRzIHRvIGJlIHNlbnQgZnJvbSB0aGUgY3VzdG9t ZXIgdG8gdGhlIFNQLCByaWdodD8NCiAgICAgICAgICAgICAgICAgICAgICAgIElmIHRoZSBjdXN0 b21lciB1c2luZyB0aGUgbW9kZWwgKGkuZS4gdGhlIFRpZXIyIGluIHlvdXIgYWJvdmUgZXhhbXBs ZSkNCiAgICAgICAgICAgICAgICAgICAgICAgIG5lZWRzIHRvIHRyYWNrIHdoaWNoIG9mIHRoZWly IG93biBjdXN0b21lcnMgdGhlIHNlcnZpY2UgaXMgZm9yLCB0aGF0J3MNCiAgICAgICAgICAgICAg ICAgICAgICAgIHNvbWV0aGluZyB0aGF0J3MgaW50ZXJuYWwgdG8gdGhlbSwgaXNuJ3QgaXQ/DQoN CiAgICAgICAgICAgICAgICBbS08zXSBZZXMsIHRoYXQncyBpbnRlcm5hbCB0byB0aGVtLCBidXQg dGhleSAoaS5lLiBvdXIgY3VzdG9tZXJzKSByZWFsbHkgcmVxdWVzdCBhbmQgYXJlIGN1cnJlbnRs eSB1c2luZyB0aGlzLiBUaGVuLCB3ZSBuZWVkIHRvIG1vZGVsIHRoaXMuDQoNCg0KICAgICAgICBQ ZXJoYXBzIEkgYW0gbWlzdW5kZXJzdGFuZGluZyB0aGUgc2NlbmFyaW8uDQoNCiAgICAgICAgSWYg SSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIGNhc2UgaXMgd2hlcmUgdGhlIHlhbmcgaXMgYmVp bmcgdXNlZCBiZXR3ZWVuIGEgVGllcjIgcHJvdmlkZXIgKGxldHMgY2FsbCB0aGVtIFQyLXRlbGVj b20pIGFuZCBUaWVyMSBwcm92aWRlciAobGV0cyBjYWxsIHRoZW0gVDEtbmV0d29ya3MpLiAgSW4g b3RoZXIgd29yZHMsIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBSRkMgYW5kIHRoZSB5YW5n IG1vZHVsZSwgVDEtbmV0d29ya3MgaXMgdGhlIFNQIGFuZCBUMi10ZWxlY29tIGlzIHRoZSBjdXN0 b21lci4NCg0KICAgICAgICBUMi10ZWxlY29tIGhhcyB0aGVpciBvd24gY3VzdG9tZXJzIGNhbGwg dGhlbSAoZm9vLWJhbmssIGJhci1zdXBlcm1hcmtldCBhbmQgYmF6LWFkdmVydGlzaW5nKS4gIFdo ZW5ldmVyIFQyLXRlbGVjb20gb3JkZXJzIGEgbmV3IFZQTiBmcm9tIFQxLW5ldHdvcmtzLCB0aGV5 IHdhbnQgdG8gcmVjb3JkLCBpbiB0aGVpciBpbnRlcm5hbCBzeXN0ZW1zLCB3aGljaCBvZiB0aGVp ciBlbmQgY3VzdG9tZXJzIHRoZSBuZXcgVlBOIGlzIGZvci4gIE9mIGNvdXJzZSB0aGVyZSBpcyBw cm9iYWJseSBhIGxvdCBvZiBvdGhlciBpbmZvcm1hdGlvbiB0aGV5IHdhbnQgdG8gc3RvcmUgaW4g dGhlaXIgaW50ZXJuYWwgc3lzdGVtcyBhYm91dCB0aGVpciBjdXN0b21lcnMsIHN1Y2ggYXMgY29u dGFjdCBpbmZvLCBiaWxsaW5nIGFuZCBpbnZvaWNpbmcgaW5mbywgdHJvdWJsZSB0aWNrZXRzLCBl dGMuDQoNCiAgICAgICAgV2hhdCBJIGRvbid0IHVuZGVyc3RhbmQgaXMgd2h5IFQyLXRlbGVjb20g d291bGQgd2FudCB0byBzZW5kIHRoZSBuYW1lIG9mIHRoZWlyIGVuZC1jdXN0b21lciAoZm9vLWJh bmssIGJhci1zdXBlcm1hcmtldCBvciBiYXotYWR2ZXJ0aXNpbmcpIHRvIFQxLW5ldHdvcmtzIGFz IHBhcnQgb2YgdGhlIG5ldGNvbmYgcmVxdWVzdCB3aGVuIHRoZXkgb3JkZXIgYSBuZXcgVlBOLiAg V2hhdCBpcyBUMS1uZXR3b3JrcyBnb2luZyB0byBkbyB3aXRoIHRoaXMgaW5mb3JtYXRpb24/DQoN CiAgICAgICAgW1Fpbl06DQoNCiAgICAgICAgMS5XaXRoIGN1c3RvbWVyIG5hbWUseW91IGNvdWxk IHVzZSBpdCBhcyBhIGtleSB0byBsb29rdXAgZGV0YWlsZWQgY3VzdG9tZXIgaW5mb3JtYXRpb24g c3VjaCBhcyBjb250YWN0IGluZm8sIGJpbGxpbmcgaW5mbyBpZiBuZWVkZWQuDQoNCiAgICAgICAg Mi4gWW91IGZvcmdldCB0aGF0IFZQTiBzZXJ2aWNlIGlzIGRlZmluZWQgYXMgYSBsaXN0IG9mIFZQ TiBTZXJ2aWNlLiBUaGF0IGlzIHRvIHNheSBkaWZmZXJlbnQgVlBOIHNlcnZpY2UgY291bGQgYmVs b25nIHRvIGRpZmZlcmVudCBjdXN0b21lciwNCg0KICAgICAgICBBZGRpbmcgY3VzdG9tZXIgbmFt ZSwgd2UgY291bGQga25vdyB3aGljaCBjdXN0b21lciBoYXMgd2hpY2ggVlBOIHNlcnZpY2UuDQoN CiAgICAgICAgMy4gY3VzdG9tZXIgbmFtZSBpcyBqdXN0IGRlZmluZWQgYXMgYW4gb3B0aW9uYWwg cGFyYW1ldGVyLiBZb3UgZG9uoa90IG5lZWQgdG8gc3BlY2lmeSBpdCBpbiB0aGUgY2FzZSB5b3Ug ZG9uoa90IG5lZWQgaXQuDQogICAgICAgICAgICBEYXZpZA0KDQoNCg0KDQogICAgICAgIC0tDQog ICAgICAgIERhdmlkIEJhbGwNCiAgICAgICAgPGRhdmliYWxsQGNpc2NvLmNvbT4gPG1haWx0bzpk YXZpYmFsbEBjaXNjby5jb20+DQoNCg0KLS0NCkRhdmlkIEJhbGwNCjxkYXZpYmFsbEBjaXNjby5j b20+IDxtYWlsdG86ZGF2aWJhbGxAY2lzY28uY29tPg0KDQoNCg== --_000_etPan59539a656b8b4567363QinWudeiPhone_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Woops, I miss to check that. Thank = for clarification.

-Qin
Sent from HUAWEI AnyOffice
=B7=A2=BC=FE=C8=CB=A3=BA ke-oogaki
=CA=D5=BC=FE=C8=CB=A3=BA Qin Wu; stephane.litkowski; l3sm; davi= ball;
=D6=F7=CC=E2=A3=BA RE: [L3sm] Next Step of RFC8049
=CA=B1=BC=E4=A3=BA 2017-06-28 19:56:23


Hi Qin,

This is already covered by Section 10.

And, I answered to David earlier.

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 fillin= g in a different customer name in the model! 
       
[KO] A customer can only access the model instance of that customer. Please= see section 10.

Thanks,
Kenichi
-----Original Message-----
From: Qin Wu [mailto:bill.wu@huawei.c= om]
Sent: Wednesday, June 28, 2017 8:30 PM
To: ke-oogaki@kddi.com; stephane.litkowski; l3sm; daviball
Subject: RE: [L3sm] Next Step of RFC8049

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

Sent from HUAWEI AnyOffice
=B7=A2=BC=FE=C8=CB=A3=BA daviball
=CA=D5=BC=FE=C8=CB=A3=BA Qin Wu; Ogaki, Kenichi; stephane.litkowski; l3sm; =
=D6=F7=CC=E2=A3=BA Re: [L3sm] Next Step of RFC8049
=CA=B1=BC=E4=A3=BA 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 acc= ess services for any other customer.

    David


On 28/06/2017 03:37, Qin Wu wrote:


        David:

        A few thoughts and comments belo= w.

        =B7=A2=BC=FE=C8=CB: David Ball [= mailto:daviball@cisco.com]
        =B7=A2=CB=CD=CA=B1=BC=E4: 2017= =C4=EA6=D4=C227=C8=D5 19:53
        =CA=D5=BC=FE=C8=CB: Ogaki, Kenic= hi; stephane.litkowski@orange.com <mailto:stephane.litkowski@orange.com> ; Qin Wu; l3sm@iet= f.org <mailto:l3sm@ietf.org>
        =D6=F7=CC=E2: Re: [L3sm] Next St= ep of RFC8049

        

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

        

        On 26/06/2017 04:23, Ogaki, Keni= chi wrote:

            &nb= sp;            =        4.   Under the VPN service, = there is a leaf for the customer name.  If the model is supposed to re= present the request from a customer to the SP, I would have thought the cus= tomer name would be known out-of-band, e.g. from the AAA for the request?  It would be bad if one customer could request t= hings for another customer by filling in a different customer name in the m= odel!
            &nb= sp;            =             &nb= sp;      
            &nb= sp;            =             [KO] A c= ustomer can only access the model instance of that customer. Please see sec= tion 10.
            &nb= sp;            =        
            &nb= sp;            =        
            &nb= sp;            =        [DB] Yes exactly - if a customer can o= nly 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 w= ith that customer's instance of the model.  It seems like the customer-name leaf is unnecessary?
            &nb= sp;            =        
            &nb= sp;            =        [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 usin= g a Tier 1 provider's VPN service. Such customers usually requires this kind of attributes for their management pu= rposes.

            &nb= sp;           [DB2]
            &nb= sp;           I didn't re= ally follow this, sorry.  The module contains the
            &nb= sp;           information= that needs to be sent from the customer to the SP, right? 
            &nb= sp;           If the cust= omer using the model (i.e. the Tier2 in your above example)
            &nb= sp;           needs to tr= ack which of their own customers the service is for, that's
            &nb= sp;           something t= hat's internal to them, isn't it?

            &nb= sp;   [KO3] Yes, that's internal to them, but they (i.e. our cust= omers) really request and are currently using this. Then, we need to model = this.

       
        Perhaps I am misunderstanding th= e scenario.
       
        If I understand correctly, the c= ase is where the yang is being used between a Tier2 provider (lets call the= m T2-telecom) and Tier1 provider (lets call them T1-networks).  In oth= er 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 custome= rs call them (foo-bank, bar-supermarket and baz-advertising).  Wheneve= r T2-telecom orders a new VPN from T1-networks, they want to record, in the= ir 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 T= 2-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 reque= st when they order a new VPN.  What is T1-networks going to do with this information?
       
        [Qin]:

        1.With customer name,you could u= se it as a key to lookup detailed customer information such as contact info= , billing info if needed.

        2. You forget that VPN service i= s defined as a list of VPN Service. That is to say different VPN service co= uld belong to different customer,

        Adding customer name, we could k= now which customer has which VPN service.

        3. customer name is just defined= as an optional parameter. You don=A1=AFt need to specify it in the case yo= u don=A1=AFt need it.
            David        
       
       

        --
        David Ball
        <daviball@cisco.com> <<= a href=3D"mailto:daviball@cisco.com">mailto:daviball@cisco.com>


--
David Ball
<daviball@cisco.com> <mailto= :daviball@cisco.com>


--_000_etPan59539a656b8b4567363QinWudeiPhone_-- From nobody Thu Jun 29 02:26:22 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E7E12EBF6 for ; Thu, 29 Jun 2017 02:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyR56wG4QsgB for ; Thu, 29 Jun 2017 02:26:19 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2411412ECBD for ; Thu, 29 Jun 2017 02:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3755; q=dns/txt; s=iport; t=1498728378; x=1499937978; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=ic7/3CZ1NTyBfSAlnx7JtStK014DisX+BvdbEr3+LXI=; b=eZU6rOy/9fAMlcoh6tC5iVx3qG3AZknejksIBl/03T5igEy573AKV50f 7LB9zx4N4LALPFuoXr/qOt+dubLtU6YKja/U6ujPT+W2Q20k+kx8/tsyG QPws05GSRwnigszGhRFiOkKgFyH+MyMt3IR/dnVnq0RzRjhvX4U7q+kFb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAAA2x1RZ/xbLJq1HFhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYVKjgVzkHSVe4IRhhwCg0wYAQIBAQEBAQEBayiFGAEBAQEDIxV?= =?us-ascii?q?NBAsRBAEBAQICDxQDAgJGCQgGAQwGAgEBiiuySYImi0kBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgQuCHINMggyCeYE8gnUpgyOCYQEEiUGHBI4xin+IdYIKhUqDS4Z?= =?us-ascii?q?4jFiIUh84gQowIQgbFYVfBxCBZz82iUEBAQE?= X-IronPort-AV: E=Sophos;i="5.40,280,1496102400"; d="scan'208";a="653933270" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 09:26:13 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5T9QBiV009314; Thu, 29 Jun 2017 09:26:11 GMT To: "Ogaki, Kenichi" , stephane.litkowski@orange.com, "'Qin Wu'" , l3sm@ietf.org References: <0a70dc6a-961d-66f2-d3a4-c7b9a48706ff@cisco.com> <00d301d2e00b$f0200ca0$d06025e0$@kddi.com> <48fc67df-aefe-a855-9c2a-0b8ca453149e@cisco.com> <006d01d2e4ed$f5f14ea0$e1d3ebe0$@kddi.com> <6f6fade7-1e5e-3cf0-e961-4d3f535eb3de@cisco.com> <6561_1498038981_594A42C5_6561_270_2_9E32478DFA9976438E7A22F69B08FF921E9C913F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7caf4c4d-b132-2e07-54c8-8e9c62727293@cisco.com> <00b101d2ee2b$8ef28ab0$acd7a010$@kddi.com> <0ed5e7de-9ab3-19a9-06ba-f0ec8a83c658@cisco.com> <002a01d2f003$b45408e0$1cfc1aa0$@kddi.com> From: David Ball Message-ID: Date: Thu, 29 Jun 2017 10:26:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <002a01d2f003$b45408e0$1cfc1aa0$@kddi.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Next Step of RFC8049 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 09:26:21 -0000 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 On 28/06/2017 12:43, Ogaki, Kenichi wrote: > 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:daviball@cisco.com] > Sent: Tuesday, June 27, 2017 8:53 PM > To: Ogaki, Kenichi; stephane.litkowski@orange.com; 'Qin Wu'; l3sm@ietf.org > Subject: Re: [L3sm] Next Step of RFC8049 > > Thanks Kenichi - there is one of your answers that I'm still confused about, see below: > > > > On 26/06/2017 04:23, Ogaki, Kenichi wrote: > > > 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. > > > [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] > 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. > > > 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 From nobody Fri Jun 30 03:02:28 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F8F12EA52 for ; Fri, 30 Jun 2017 03:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUEMpVxrWcmV for ; Fri, 30 Jun 2017 03:02:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6EB8129C0B for ; Fri, 30 Jun 2017 03:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9572; q=dns/txt; s=iport; t=1498816944; x=1500026544; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vT9I+Buomm26bFN9h7FoOin79qPB92Hy2roxGgJ+S3s=; b=TKIZJoTZGSnV+8nLCqkjRDMahM1SPdo7lqjeerPGoamGLf4IvNIL9MML fduGCp0nvsSsIvfiCcNb9gS3PXVxfywy3o3Efw83UPz9jjTgNpznGvn94 4PZ5VtEwN3JyWIkiut39AmNqaE71Igbhd0e4C+4hLiJiVve90/lf/mMdl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAAAfIVZZ/5JdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9qY4EVjX6iOoUrghEshXACgxU/GAECAQEBAQEBAWsohRkGeRACAQg?= =?us-ascii?q?OODIlAgQOiVBkELYFi0EBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMng0yBYSuBb?= =?us-ascii?q?YEMiC2CMQWeegKHQow6ggyFSopElSwBHziBCnUVSRIBhQUXgWaJE4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,285,1496102400"; d="scan'208,217";a="264282077" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jun 2017 10:02:23 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v5UA2NmG007505 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Jun 2017 10:02:23 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 30 Jun 2017 05:02:23 -0500 Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1210.000; Fri, 30 Jun 2017 05:02:23 -0500 From: "Jan Lindblad (jlindbla)" To: Qin Wu CC: "l3sm@ietf.org" , "Benoit Claise (bclaise)" , "adrian@olddog.co.uk" Thread-Topic: [L3sm] I-D Action: draft-wu-l3sm-rfc8049bis-00.txt Thread-Index: AQHS60/al72SWIj7YEiowZPt9ZDOi6IwyWmAgAzDtwA= Date: Fri, 30 Jun 2017 10:02:23 +0000 Message-ID: <4C624736-109A-4B25-9B4D-11B04BDF652D@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.86] Content-Type: multipart/alternative; boundary="_000_4C624736109A4B259B4D11B04BDF652Dciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [L3sm] I-D Action: draft-wu-l3sm-rfc8049bis-00.txt X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 10:02:27 -0000 --_000_4C624736109A4B259B4D11B04BDF652Dciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Qin, Hi,L3SMers: Thank Jan for excellent YANG doctor review and valuable inputs based on Ser= vice Model deployment experience. Thanks for L3SM design team to engage in the discussion on the list and hel= p address all of comments. Here is the initial version of RFC8049bis. https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-00 Jan, please review it and let us know if you have any additional comments. I had a quick scan and I think it all looks good. Tried all the examples. P= retty much all of them still have a lot of dependencies on data not provide= d and omit many mandatory fields. We can live with that. I found two examples with minor mistakes in them. Line 4597: VPNA SITE1 static 192.0.2.0/24 203.0.113.1/32 The next-hop address is modeled as inet:ipv4-address, so the above value is= invalid. Should be: "203.0.113.1" Line 5070: VPNA SITE1 SvrA-http 192.0.2.0/24 203.0.113.1/32 80 tcp The leaf I believe the example author is thinking of is called . There is no leaf called protocol-type at this location, even if the t= ype of the leaf protocol-field is called so. The Swedish vacation season is on; I won't have time for more reviews until= the beginning of August. Have a great summer! ;-) Best Regards, /jan --_000_4C624736109A4B259B4D11B04BDF652Dciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Qin,

Hi,L3SMers:
Thank Jan for excellent YANG doctor review and valuable inputs based on Ser= vice Model deployment experience.
Thanks for L3SM design team to engage in the discussion on the list and hel= p address all of comments.
Here is the initial version of RFC8049bis.
https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-00
Jan, please review it and let us know if you have any additional comments.<= br class=3D"">

I had a quick scan and I think it all looks good. Tried all the exampl= es. Pretty much all of them still have a lot of dependencies on data not pr= ovided and omit many mandatory fields. We can live with that.

I found two examples with minor mistakes in them.

Line 4597:

      <?xml version=3D"1.0"?>
      <l3vpn-svc xmlns=3D"urn:ietf:params:xml:n= s:yang:ietf-l3vpn-svc">
        <vpn-services>
          <vpn-service>
            <vpn-id>VPNA</vpn-i= d>
          </vpn-service>
        </vpn-services>
        <sites>
          <site>
            <site-id>SITE1</sit= e-id>
            <routing-protocols>
              <routing-protocol&= gt;
                <type>st= atic</type>
                <static>=
                    =           <cascaded-lan-prefixes>
                  <ipv= 4-lan-prefixes>
                  <lan= >192.0.2.0/24</lan>
                =   <next-hop>203.0.113.1/32</next-hop>

The next-hop address is modeled as inet:ipv4-address, so the above val= ue is invalid. Should be: "203.0.113.1"

Line 5070:

     <?xml version=3D"1.0"?>
     <l3vpn-svc xmlns=3D"urn:ietf:params:xml:ns= :yang:ietf-l3vpn-svc">
       <vpn-services>
         <vpn-service>
           <vpn-id>VPNA</vpn-id= >
         </vpn-service>
       </vpn-services>
       <sites>
         <site>
           <site-id>SITE1</site= -id>
           <service>
             <qos>
               <qos-classif= ication-policy>
                 <rule= >
                   &= lt;id>SvrA-http</id>
                   &= lt;match-flow>
                    =  <ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
                    =  <ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
                    =  <l4-dst-port>80</l4-dst-port>
                =      <protocol-type>tcp</protocol-type>

The leaf I believe the example author is thinking of is called <pro= tocol-field>. There is no leaf called protocol-type at this location, ev= en if the type of the leaf protocol-field is called so.

The Swedish vacation season is on; I won't have time for more reviews = until the beginning of August. Have a great summer! ;-)

Best Regards,
/jan

--_000_4C624736109A4B259B4D11B04BDF652Dciscocom_-- From nobody Fri Jun 30 05:03:05 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA0D127286 for ; Fri, 30 Jun 2017 05:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEzNW4d9VTK8 for ; Fri, 30 Jun 2017 05:03:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3888126D73 for ; Fri, 30 Jun 2017 05:03:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJM41852; Fri, 30 Jun 2017 12:02:58 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 30 Jun 2017 13:02:57 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 30 Jun 2017 20:02:53 +0800 From: Qin Wu To: "Jan Lindblad (jlindbla)" CC: "l3sm@ietf.org" , "Benoit Claise (bclaise)" , "adrian@olddog.co.uk" Thread-Topic: [L3sm] I-D Action: draft-wu-l3sm-rfc8049bis-00.txt Thread-Index: AQHS60/al72SWIj7YEiowZPt9ZDOi6IwyWmAgAzDtwD//80ZEA== Date: Fri, 30 Jun 2017 12:02:52 +0000 Message-ID: References: <4C624736-109A-4B25-9B4D-11B04BDF652D@cisco.com> In-Reply-To: <4C624736-109A-4B25-9B4D-11B04BDF652D@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A98EC7Bnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59563DF3.00EC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8b451b64da6a4289db8dc6b2713d8a2e Archived-At: Subject: Re: [L3sm] I-D Action: draft-wu-l3sm-rfc8049bis-00.txt X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 12:03:04 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9A98EC7Bnkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmsgSmFuIGZvciBxdWljayBmZWVkYmFjaywgV2Ugd2lsbCBmaXggbWlzdGFrZSB5b3UgcmFp c2VkIGluIHRoZSBuZXh0IHVwZGF0ZS4NCkhhdmUgYSBnb29kIHZhY2F0aW9uLiA6KQ0KDQotUWlu DQq3orz+yMs6IEphbiBMaW5kYmxhZCAoamxpbmRibGEpIFttYWlsdG86amxpbmRibGFAY2lzY28u Y29tXQ0Kt6LLzcqxvOQ6IDIwMTfE6jbUwjMwyNUgMTg6MDINCsrVvP7IyzogUWluIFd1DQqzrcvN OiBsM3NtQGlldGYub3JnOyBCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKTsgYWRyaWFuQG9sZGRvZy5j by51aw0K1vfM4jogUmU6IFtMM3NtXSBJLUQgQWN0aW9uOiBkcmFmdC13dS1sM3NtLXJmYzgwNDli aXMtMDAudHh0DQoNClFpbiwNCg0KSGksTDNTTWVyczoNClRoYW5rIEphbiBmb3IgZXhjZWxsZW50 IFlBTkcgZG9jdG9yIHJldmlldyBhbmQgdmFsdWFibGUgaW5wdXRzIGJhc2VkIG9uIFNlcnZpY2Ug TW9kZWwgZGVwbG95bWVudCBleHBlcmllbmNlLg0KVGhhbmtzIGZvciBMM1NNIGRlc2lnbiB0ZWFt IHRvIGVuZ2FnZSBpbiB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBhbmQgaGVscCBhZGRyZXNz IGFsbCBvZiBjb21tZW50cy4NCkhlcmUgaXMgdGhlIGluaXRpYWwgdmVyc2lvbiBvZiBSRkM4MDQ5 YmlzLg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LWwzc20tcmZjODA0OWJp cy0wMA0KSmFuLCBwbGVhc2UgcmV2aWV3IGl0IGFuZCBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBh bnkgYWRkaXRpb25hbCBjb21tZW50cy4NCg0KSSBoYWQgYSBxdWljayBzY2FuIGFuZCBJIHRoaW5r IGl0IGFsbCBsb29rcyBnb29kLiBUcmllZCBhbGwgdGhlIGV4YW1wbGVzLiBQcmV0dHkgbXVjaCBh bGwgb2YgdGhlbSBzdGlsbCBoYXZlIGEgbG90IG9mIGRlcGVuZGVuY2llcyBvbiBkYXRhIG5vdCBw cm92aWRlZCBhbmQgb21pdCBtYW55IG1hbmRhdG9yeSBmaWVsZHMuIFdlIGNhbiBsaXZlIHdpdGgg dGhhdC4NCg0KSSBmb3VuZCB0d28gZXhhbXBsZXMgd2l0aCBtaW5vciBtaXN0YWtlcyBpbiB0aGVt Lg0KDQpMaW5lIDQ1OTc6DQoNCiAgICAgIDw/eG1sIHZlcnNpb249IjEuMCI/Pg0KICAgICAgPGwz dnBuLXN2YyB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtbDN2cG4tc3Zj Ij4NCiAgICAgICAgPHZwbi1zZXJ2aWNlcz4NCiAgICAgICAgICA8dnBuLXNlcnZpY2U+DQogICAg ICAgICAgICA8dnBuLWlkPlZQTkE8L3Zwbi1pZD4NCiAgICAgICAgICA8L3Zwbi1zZXJ2aWNlPg0K ICAgICAgICA8L3Zwbi1zZXJ2aWNlcz4NCiAgICAgICAgPHNpdGVzPg0KICAgICAgICAgIDxzaXRl Pg0KICAgICAgICAgICAgPHNpdGUtaWQ+U0lURTE8L3NpdGUtaWQ+DQogICAgICAgICAgICA8cm91 dGluZy1wcm90b2NvbHM+DQogICAgICAgICAgICAgIDxyb3V0aW5nLXByb3RvY29sPg0KICAgICAg ICAgICAgICAgIDx0eXBlPnN0YXRpYzwvdHlwZT4NCiAgICAgICAgICAgICAgICA8c3RhdGljPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGNhc2NhZGVkLWxhbi1wcmVmaXhlcz4NCiAg ICAgICAgICAgICAgICAgIDxpcHY0LWxhbi1wcmVmaXhlcz4NCiAgICAgICAgICAgICAgICAgIDxs YW4+MTkyLjAuMi4wLzI0PC9sYW4+DQogICAgICAgICAgICAgICAgICA8bmV4dC1ob3A+MjAzLjAu MTEzLjEvMzI8L25leHQtaG9wPg0KDQpUaGUgbmV4dC1ob3AgYWRkcmVzcyBpcyBtb2RlbGVkIGFz IGluZXQ6aXB2NC1hZGRyZXNzLCBzbyB0aGUgYWJvdmUgdmFsdWUgaXMgaW52YWxpZC4gU2hvdWxk IGJlOiAiMjAzLjAuMTEzLjEiDQoNCkxpbmUgNTA3MDoNCg0KICAgICA8P3htbCB2ZXJzaW9uPSIx LjAiPz4NCiAgICAgPGwzdnBuLXN2YyB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5n OmlldGYtbDN2cG4tc3ZjIj4NCiAgICAgICA8dnBuLXNlcnZpY2VzPg0KICAgICAgICAgPHZwbi1z ZXJ2aWNlPg0KICAgICAgICAgICA8dnBuLWlkPlZQTkE8L3Zwbi1pZD4NCiAgICAgICAgIDwvdnBu LXNlcnZpY2U+DQogICAgICAgPC92cG4tc2VydmljZXM+DQogICAgICAgPHNpdGVzPg0KICAgICAg ICAgPHNpdGU+DQogICAgICAgICAgIDxzaXRlLWlkPlNJVEUxPC9zaXRlLWlkPg0KICAgICAgICAg ICA8c2VydmljZT4NCiAgICAgICAgICAgICA8cW9zPg0KICAgICAgICAgICAgICAgPHFvcy1jbGFz c2lmaWNhdGlvbi1wb2xpY3k+DQogICAgICAgICAgICAgICAgIDxydWxlPg0KICAgICAgICAgICAg ICAgICAgIDxpZD5TdnJBLWh0dHA8L2lkPg0KICAgICAgICAgICAgICAgICAgIDxtYXRjaC1mbG93 Pg0KICAgICAgICAgICAgICAgICAgICAgPGlwdjQtc3JjLXByZWZpeD4xOTIuMC4yLjAvMjQ8L2lw djQtc3JjLXByZWZpeD4NCiAgICAgICAgICAgICAgICAgICAgIDxpcHY0LWRzdC1wcmVmaXg+MjAz LjAuMTEzLjEvMzI8L2lwdjQtZHN0LXByZWZpeD4NCiAgICAgICAgICAgICAgICAgICAgIDxsNC1k c3QtcG9ydD44MDwvbDQtZHN0LXBvcnQ+DQogICAgICAgICAgICAgICAgICAgICA8cHJvdG9jb2wt dHlwZT50Y3A8L3Byb3RvY29sLXR5cGU+DQoNClRoZSBsZWFmIEkgYmVsaWV2ZSB0aGUgZXhhbXBs ZSBhdXRob3IgaXMgdGhpbmtpbmcgb2YgaXMgY2FsbGVkIDxwcm90b2NvbC1maWVsZD4uIFRoZXJl IGlzIG5vIGxlYWYgY2FsbGVkIHByb3RvY29sLXR5cGUgYXQgdGhpcyBsb2NhdGlvbiwgZXZlbiBp ZiB0aGUgdHlwZSBvZiB0aGUgbGVhZiBwcm90b2NvbC1maWVsZCBpcyBjYWxsZWQgc28uDQoNClRo ZSBTd2VkaXNoIHZhY2F0aW9uIHNlYXNvbiBpcyBvbjsgSSB3b24ndCBoYXZlIHRpbWUgZm9yIG1v cmUgcmV2aWV3cyB1bnRpbCB0aGUgYmVnaW5uaW5nIG9mIEF1Z3VzdC4gSGF2ZSBhIGdyZWF0IHN1 bW1lciEgOy0pDQoNCkJlc3QgUmVnYXJkcywNCi9qYW4NCg0K --_000_B8F9A780D330094D99AF023C5877DABA9A98EC7Bnkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thank Jan = for quick feedback, We will fix mistake you raised in the next update.=

Have a goo= d vacation. J

 = ;

-Qin<= /o:p>

=B7=A2=BC=FE=C8=CB: Jan Lindblad (jlindbl= a) [mailto:jlindbla@cisco.com]
=B7=A2=CB=CD= =CA=B1=BC=E4: 2017=C4=EA6=D4=C2<= span lang=3D"EN-US">30=C8=D5 18:02
=CA=D5=BC=FE=C8=CB: Qin Wu
=B3=AD=CB=CD: l3sm@ietf.org; Benoit Claise (bclaise); adrian@olddog.co.uk
=D6=F7=CC=E2: Re: [L3sm] I-D Action: draft-wu-l3sm-rfc8049bis-00.txt<= /span>

 

Qin,

 

Hi,L3SMers:
Thank Jan for excellent YANG doctor review and valuable inputs based on Ser= vice Model deployment experience.
Thanks for L3SM design team to engage in the discussion on the list and hel= p address all of comments.
Here is the initial version of RFC8049bis.
https:/= /tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-00
Jan, please review it and let us know if you have any additional comments.<= o:p>

 

I had a quick scan and I think = it all looks good. Tried all the examples. Pretty much all of them still ha= ve a lot of dependencies on data not provided and omit many mandatory field= s. We can live with that.

 

I found two examples with minor= mistakes in them.

 

Line 4597:

 

      <?xml v= ersion=3D"1.0"?>

      <l3vpn-= svc xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">=

        <= ;vpn-services>

        &nb= sp; <vpn-service>

        &nb= sp;   <vpn-id>VPNA</vpn-id>

        &nb= sp; </vpn-service>

        <= ;/vpn-services>

        <= ;sites>

        &nb= sp; <site>

        &nb= sp;   <site-id>SITE1</site-id>

        &nb= sp;   <routing-protocols>

        &nb= sp;     <routing-protocol>

        &nb= sp;       <type>static</type><= /p>

        &nb= sp;       <static>

        &nb= sp;                     &= lt;cascaded-lan-prefixes>

        &nb= sp;         <ipv4-lan-prefixes>=

        &nb= sp;         <lan>192.0.2.0/24</lan>

        =           <next-hop>203.0.113.1/32</next-= hop>

 

The next-hop address is modeled= as inet:ipv4-address, so the above value is invalid. Should be: "203.= 0.113.1"

 

Line 5070:

 

     <?xml ve= rsion=3D"1.0"?>

     <l3vpn-s= vc xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"><= /o:p>

       <= vpn-services>

        &nb= sp;<vpn-service>

        &nb= sp;  <vpn-id>VPNA</vpn-id>

        &nb= sp;</vpn-service>

       <= /vpn-services>

       <= sites>

        &nb= sp;<site>

        &nb= sp;  <site-id>SITE1</site-id>

        &nb= sp;  <service>

        &nb= sp;    <qos>

        &nb= sp;      <qos-classification-policy>=

        &nb= sp;        <rule>

        &nb= sp;          <id>SvrA-http</id>

        &nb= sp;          <match-flow><= /p>

        &nb= sp;            <ipv4-src-prefix>192.0.2= .0/24</ipv4-src-prefix>

        &nb= sp;            <ipv4-dst-prefix>203.0.1= 13.1/32</ipv4-dst-prefix>

        &nb= sp;            <l4-dst-port>80</l4-d= st-port>

        =              <protocol-type>tcp<= ;/protocol-type>

 

The leaf I believe the example = author is thinking of is called <protocol-field>. There is no leaf ca= lled protocol-type at this location, even if the type of the leaf protocol-= field is called so.

 

The Swedish vacation season is = on; I won't have time for more reviews until the beginning of August. Have = a great summer! ;-)

 

Best Regards,=

/jan

 

--_000_B8F9A780D330094D99AF023C5877DABA9A98EC7Bnkgeml513mbxchi_--