From nobody Thu Apr 14 04:54:59 2016 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 2358C12DEE6; Thu, 14 Apr 2016 03:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 bxDLwSQ9fS3H; Thu, 14 Apr 2016 03:56:16 -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 0FA9112DF46; Thu, 14 Apr 2016 03:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25590; q=dns/txt; s=iport; t=1460631375; x=1461840975; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=DWbnyvTKfjdlPak3ShgW/j/4Bdovdpkxzcyse/gyzvQ=; b=F/W/i0vVdQNDlFS43M27T0QjgXBJMvjcrHwzpGFGu383CJjjH3TCzpLH 0o1SS41/bVt/8wLrYyYr2ETgZKf1hPjveUyAnGaXGCTNUu7Y7zgkYdq/E AJoNymFOG4NOsqo/zlOLVjYSBf+WRBoXUln7G+VC4T0i9xeGfGh8PcOVs 0=; X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208,217";a="635179379" 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; 14 Apr 2016 10:56:13 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3EAuCM7018643; Thu, 14 Apr 2016 10:56:12 GMT To: Liaison Statement Management Tool , ietf@wjcerveny.com, joelja@bogus.com, adrian@olddog.co.uk, rcallon@juniper.net, ietf@trammell.ch, swallow.ietf@gmail.com, bill.wu@huawei.com, loa@pi.nu References: <20160226180541.18278.30437.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <570F774B.1080907@cisco.com> Date: Thu, 14 Apr 2016 12:56:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160226180541.18278.30437.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080402020209000801080607" Archived-At: X-Mailman-Approved-At: Thu, 14 Apr 2016 04:54:58 -0700 Cc: L3VPN Service Model Discussion List , Multiprotocol Label Switching Discussion List , Deborah Brungard , IP Performance Metrics Discussion List , Bill Bjorkman , Nan Chen , Alia Atlas , Martin Stiemerling , The IETF Chair , Spencer Dawkins , rraghu@ciena.com, Alvaro Retana Subject: Re: [L3sm] New Liaison Statement, "Liaison from MEF on IP Service Attributes" X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 10:56:20 -0000 This is a multi-part message in MIME format. --------------080402020209000801080607 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, The L3SM, IPPM, MPLS, and the OPS Area would like to thank the MEF for informing us of your effort on IP Service Attributes [1]. We're pleased that you mentioned the L3VPN service model (L3SM) work in your liaison. The L3SM work covers an abstracted view of the Layer 3 IPVPN service configuration components, with its "YANG Data Model for L3VPN service delivery" [2] deliverable. From your liaison statement, we read "In MEF terms, a "service" refers to the set of attributes and their values that are agreed between the provider of a service and the customer of that service." You will be glad to hear that we use the same definition in our L3SM work. As such, the MEF initiative on IP service attributes clearly relates to L3SM. The L3SM chairs and working group have examined the proposed scope of the initial phase of the MEF IP Service Attributes project: -Definition of attributes for IP-capable UNIs and NNIs, for IP Service connections, and for IP Service End Points at UNIs and ENNIs -IP address allocations and IP control protocols (e.g. DHCP) etc at UNIs -OAM across the external interface (by reference to IETF protocols and mechanisms) -Service Level Specification (SLS) definitions including performance monitoring/constraints (by reference to IETF protocols and metric definitions) -Redundant links at an external interface (Subscriber/Service provider or between Service Providers), including options for different routing protocols. -Multi-CoS services (i.e. QoS classification) and classification of Green/Yellow packets including diffserv, Bandwidth profiles, etc. -IPv4, IPv6 and dual stack services -Inter-operator IP-VPN services using options A, B or C from RFC4364 -Unicast only (multicast is defered to a future phase). -Other topics may be added as the project progresses. The L3SM work already covers most of the items in this list, including multicast. However, we should observe that: 1. L3SM has initially focused on the interface between the customer and the service provider, not the interface between services providers or between service provider domains. The current service model supports the configuration of the RFC 4364 option A (as this is a subset of the existing site model), and we're considering whether to add option B and C. 2. The L3SM work does not cover either the Service Level Specification definitions or the Lifecycle Service Orchestration as described in the MEF Lifecycle Service Orchestration (LSO) Reference Architecture & Framework. The L3SM work started about a year ago and is in the final stage of standardization. Therefore, we would encourage anyone who is interested to review and provide feedback on the future standard by sending a message to the L3SM mailing list as soon as possible (details at [3]). Please keep us informed of any gaps you identify that are needed to satisfy the requirements in your specifications, without the need for a formal liaison. I hope you will agree that it is important to not duplicate work within standardization. Therefore, I hope you will work to produce extensions to the L3SM YANG model for additional features such as the Service Level Specification, and will not repeat any of the function already provided by that model. If you need further information, don't hesitate to contact us. We are always available for further discussions or conference calls regarding the L3SM specifications content. Regards, Benoit Claise (OPS Area Director) [1] https://datatracker.ietf.org/liaison/1458/ [2] https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/ [3] https://datatracker.ietf.org/wg/l3sm/charter/ > Title: Liaison from MEF on IP Service Attributes > Submission Date: 2016-02-26 > URL of the IETF Web page: https://datatracker.ietf.org/liaison/1458/ > > From: "Raghu Ranganathan" > To: bclaise@cisco.com, joelja@bogus.com, ietf@trammell.ch>, ietf@wjcerveny.com, loa@pi.nu, swallow.ietf@gmail.com, rcallon@juniper.net, adrian@olddog.co.uk, bill.wu@huawei.com > Cc: Alvaro Retana ,Joel Jaeggli ,Deborah Brungard ,IP Performance Metrics Discussion List ,Multiprotocol Label Switching Discussion List ,Adrian Farrel ,Qin Wu ,Bill Cerveny ,Brian Trammell ,Spencer Dawkins ,George Swallow ,Alia Atlas ,The IETF Chair ,Nan Chen ,Ross Callon ,Loa Andersson ,Benoit Claise ,L3VPN Service Model Discussion List ,Bill Bjorkman ,Martin Stiemerling ,Raghu Ranganathan , > Response Contacts: rraghu@ciena.com > Technical Contacts: > Purpose: For information > > Body: We would like to inform you that during our 1Q2016 meeting, MEF has approved a new project on IP Service Attributes. We have set out some background and further details below. > > MEF is well known for the definition of Carrier Ethernet (CE) services (in MEF 6.2, MEF 33 and MEF 51) based on service attributes (defined in MEF 10.3 and MEF 26.1). In MEF terms, a "service" refers to the set of attributes and their values that are agreed between the provider of a serviceand the customer of that service. These attributes are independent of how the service is implemented; for example a CE service could be > implemented using Provider Backbone Bridging (802.1Q) or using VPLS (RFC 4761/4762) to provide the connectivity across the service provider's network. MEF defines both end-to-end services agreed between a subscriber and a service provider, where the end points are all User-Network Interfaces (UNIs), and inter-provider services supplied by one service provider or operator to another, where the end points may be UNIs or External Network-Network Interfaces (ENNIs). > > Note that this differs from how the word "service" is sometimes used in IETF, e.g. to describe a particular technology (as in "Virtual Private LAN Service"). > > Although IP Services are widely deployed, there is currently no standard definition of the attributes and values used to describe them. Each Service Provider has their own way of describing IP services (including in some cases their own terminology); this makes it hard for customers to compare service offerings from different providers, and in particular makes it hard for providers to interconnect with each other – each Service Provider must form a specific bilateral agreement with each other Service Provider they wish to connect with. > > Furthermore, there is a desire among service providers to improve service delivery times by automating the service ordering and configuration process. This is a key aspect of MEF Lifecycle Services Orchestration (LSO). The aim of MEF LSO is to deliver the MEF Third Network vision, to provide Assured, Agile and Orchestrated services. MEF LSO enables automation and orchestration of service ordering and management between service providers ("East/West interfaces") through the creation of standard data models and APIs. However, a pre-requisite for defining those is to have a standard definition of the service that is to be managed. > > The new project is intended to address these issues by providing a standard definition of IP Services, including both end-to-end services and inter-provider services, through the definition of a standard set of Service Attributes that can be used in each case. The scope is limited to IP-VPN and Internet Access services (IP peering/transit for internet traffic is precluded). It is intended that this project is the first step in enabling multi-operator service orchestration of IP Services using MEF LSO, and that later projects will use the Service Attributes to create standard data models and APIs. The intent of LSO is to provide a common framework across different service technologies; MEF is working with TMF and ONF to create common models for services, and the standard data models and APIs for IP Services will tie into this framework. > > We have noted that IETF is working on a Yang model for Layer 3 Services in the L3SM working group. Although the scope of that project in IETF is different, it is clear there is some synergy between the L3SM work and this MEF project. We believe that both projects can benefit from input from each other and we hope to work closely with the L3SM working group to ensure our specifications are aligned. > > The scope of the initial phase of the IP Service Attributes project includes: > -Definition of attributes for IP-capable UNIs and NNIs, for IP Service connections, and for IP Service End Points at UNIs and ENNIs > -IP address allocations and IP control protocols (e.g. DHCP) etc at UNIs > -OAM across the external interface (by reference to IETF protocols and mechanisms) > -Service Level Specification (SLS) definitions including performance monitoring/constraints (by reference to IETF protocols and metric definitions) > -Redundant links at an external interface (Subscriber/Service provider or between Service Providers), including options for different routing protocols. > -Multi-CoS services (i.e. QoS classification) and classification of Green/Yellow packets including diffserv, Bandwidth profiles, etc. > -IPv4, IPv6 and dual stack services > -Inter-operator IP-VPN services using options A, B or C from RFC4364 > -Unicast only (multicast is defered to a future phase). > -Other topics may be added as the project progresses. > > It is important to note that we intend to make extensive reference to existing IETF RFCs where applicable; it is not our intent to specify new protocols or mechanisms where there are existing solutions. > > Note: further information about MEF LSO can be found in the LSO Reference Architecture. The final verison is expected to be published in March; in the meantime, the latest approved draft is available as below: > https://mef.net/liaison-login > Username: mef > Attachments: > > Liaison > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-02-26-mef-ippm-mpls-l3sm-ops-liaison-from-mef-on-ip-service-attributes-attachment-1.pdf > > . > --------------080402020209000801080607 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,

The L3SM, IPPM, MPLS, and the OPS Area would like to thank the MEF for informing us of your effort on IP Service Attributes  [1].

We're pleased that you mentioned the L3VPN service model (L3SM) work in your liaison. The L3SM work covers an abstracted view of the Layer 3 IPVPN service configuration components, with its "YANG Data Model for L3VPN service delivery" [2] deliverable.

From your liaison statement, we read "In MEF terms, a "service" refers to the set of attributes and their values that are agreed between the provider of a service and the customer of that service." You will be glad to hear that we use the same definition in our L3SM work. As such, the MEF initiative on IP service attributes clearly relates to L3SM.

The L3SM chairs and working group have examined the proposed scope of the initial phase of the MEF IP Service Attributes project:
-Definition of attributes for IP-capable UNIs and NNIs, for IP Service connections, and for IP Service End Points at UNIs and ENNIs
-IP address allocations and IP control protocols (e.g. DHCP) etc at UNIs
-OAM across the external interface (by reference to IETF protocols and
mechanisms)
-Service Level Specification (SLS) definitions including performance monitoring/constraints (by reference to IETF protocols and metric definitions)
-Redundant links at an external interface (Subscriber/Service provider or between Service Providers), including options for different routing protocols.
-Multi-CoS services (i.e. QoS classification) and classification of
Green/Yellow packets including diffserv, Bandwidth profiles, etc.
-IPv4, IPv6 and dual stack services
-Inter-operator IP-VPN services using options A, B or C from RFC4364
-Unicast only (multicast is defered to a future phase).
-Other topics may be added as the project progresses.

The L3SM work already covers most of the items in this list, including multicast.  However, we should observe that:
1.  L3SM has initially focused on the interface between the customer and the service provider, not the interface between services providers or between service provider domains. The current service model supports the configuration of the RFC 4364 option A (as this is a subset of the existing site model), and we're considering whether to add option B and C.
2.  The L3SM work does not cover either the Service Level Specification definitions or the Lifecycle Service Orchestration as described in the MEF Lifecycle Service Orchestration (LSO) Reference Architecture & Framework.

The L3SM work started about a year ago and is in the final stage of standardization. Therefore, we would encourage anyone who is interested to review and provide feedback on the future standard by sending a message to the L3SM mailing list as soon as possible (details at [3]). Please keep us informed of any gaps you identify that are needed to satisfy the requirements in your specifications, without the need for a formal liaison.

I hope you will agree that it is important to not duplicate work within standardization. Therefore, I hope you will work to produce extensions to the L3SM YANG model for additional features such as the Service Level Specification, and will not repeat any of the function already provided by that model. If you need further information, don't hesitate to contact us. We are always available for further discussions or conference calls regarding the L3SM specifications content.

Regards, Benoit Claise (OPS Area Director)

[1] https://datatracker.ietf.org/liaison/1458/
[2] https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/
[3] https://datatracker.ietf.org/wg/l3sm/charter/



Title: Liaison from MEF on IP Service Attributes
Submission Date: 2016-02-26
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1458/

From: "Raghu Ranganathan" <rraghu@ciena.com>
To: bclaise@cisco.com, joelja@bogus.com, ietf@trammell.ch>, ietf@wjcerveny.com, loa@pi.nu, swallow.ietf@gmail.com, rcallon@juniper.net, adrian@olddog.co.uk, bill.wu@huawei.com
Cc: Alvaro Retana <aretana@cisco.com>,Joel Jaeggli <joelja@bogus.com>,Deborah Brungard <db3546@att.com>,IP Performance Metrics Discussion List <ippm@ietf.org>,Multiprotocol Label Switching Discussion List <mpls@ietf.org>,Adrian Farrel <adrian@olddog.co.uk>,Qin Wu <bill.wu@huawei.com>,Bill Cerveny <ietf@wjcerveny.com>,Brian Trammell <iet
f@trammell.ch>,Spencer Dawkins <spencerdawkins.ietf@gmail.com>,George Swallow <swallow.ietf@gmail.com>,Alia Atlas <akatlas@gmail.com>,The IETF Chair <chair@ietf.org>,Nan Chen <nan@metroethernetforum.org>,Ross Callon <rcallon@juniper.net>,Loa Andersson <loa@pi.nu>,Benoit Claise <bclaise@cisco.com>,L3VPN Service Model  Discussion List <l3sm@ietf.org>,Bill Bjorkman <bill@metroethernetforum.net>,Martin Stiemerling <mls.ietf@gmail.com>,Raghu Ranganathan <rraghu@ciena.com>,
Response Contacts: rraghu@ciena.com
Technical Contacts: 
Purpose: For information

Body: We would like to inform you that during our 1Q2016 meeting, MEF has approved a new project on IP Service Attributes. We have set out some background and further details below.

MEF is well known for the definition of Carrier Ethernet (CE) services (in MEF 6.2, MEF 33 and MEF 51) based on service attributes (defined in MEF 10.3 and MEF 26.1). In MEF terms, a "service" refers to the set of attributes and their values that are agreed between the provider of a serviceand the customer of that service. These attributes are independent of how the service is implemented; for example a CE service could be
implemented using Provider Backbone Bridging (802.1Q) or using VPLS (RFC 4761/4762) to provide the connectivity across the service provider's network. MEF defines both end-to-end services agreed between a subscriber and a service provider, where the end points are all User-Network Interfaces (UNIs), and inter-provider services supplied by one service provider or operator to another, where the end points may be UNIs or External Network-Network Interfaces (ENNIs).

Note that this differs from how the word "service" is sometimes used in IETF, e.g. to describe a particular technology (as in "Virtual Private LAN Service").

Although IP Services are widely deployed, there is currently no standard definition of the attributes and values used to describe them. Each Service Provider has their own way of describing IP services (including in some cases their own terminology); this makes it hard for customers to compare service offerings from different providers, and in particular makes it hard for providers to interconnect with each other – each Service Provider must form a specific bilateral agreement with each other Service Provider they wish to connect with.

Furthermore, there is a desire among service providers to improve service delivery times by automating the service ordering and configuration process. This is a key aspect of MEF Lifecycle Services Orchestration (LSO). The aim of MEF LSO is to deliver the MEF Third Network vision, to provide Assured, Agile and Orchestrated services. MEF LSO enables automation and orchestration of service ordering and management between service providers ("East/West interfaces") through the creation of standard data models and APIs. However, a pre-requisite for defining those is to have a standard definition of the service that is to be managed.

The new project is intended to address these issues by providing a standard definition of IP Services, including both end-to-end services and inter-provider services, through the definition of a standard set of Service Attributes that can be used in each case. The scope is limited to IP-VPN and Internet Access services  (IP peering/transit for internet traffic is precluded). It is intended that this project is the first step in enabling multi-operator service orchestration of IP Services using MEF LSO, and that later projects will use the Service Attributes to create standard data models and APIs. The intent of LSO is to provide a common framework across different service technologies; MEF is working with TMF and ONF to create common models for services, and the standard data models and APIs for IP Services will tie into this framework.

We have noted that IETF is working on a Yang model for Layer 3 Services in the L3SM working group. Although the scope of that project in IETF is different, it is clear there is some synergy between the L3SM work and this MEF project. We believe that both projects can benefit from input from each other and we hope to work closely with the L3SM working group to ensure our specifications are aligned.

The scope of the initial phase of the IP Service Attributes project includes:
-Definition of attributes for IP-capable UNIs and NNIs, for IP Service connections, and for IP Service End Points at UNIs and ENNIs
-IP address allocations and IP control protocols (e.g. DHCP) etc at UNIs
-OAM across the external interface (by reference to IETF protocols and mechanisms)
-Service Level Specification (SLS) definitions including performance monitoring/constraints (by reference to IETF protocols and metric definitions)
-Redundant links at an external interface (Subscriber/Service provider or between Service Providers), including options for different routing protocols.
-Multi-CoS services (i.e. QoS classification) and classification of Green/Yellow packets including diffserv, Bandwidth profiles, etc.
-IPv4, IPv6 and dual stack services
-Inter-operator IP-VPN services using options A, B or C from RFC4364
-Unicast only (multicast is defered to a future phase).
-Other topics may be added as the project progresses.

It is important to note that we intend to make extensive reference to existing IETF RFCs where applicable; it is not our intent to specify new protocols or mechanisms where there are existing solutions.

Note: further information about MEF LSO can be found in the LSO Reference Architecture. The final verison is expected to be published in March; in the meantime, the latest approved draft is available as below:
https://mef.net/liaison-login
Username: mef
Attachments:

    Liaison
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-02-26-mef-ippm-mpls-l3sm-ops-liaison-from-mef-on-ip-service-attributes-attachment-1.pdf

.

--------------080402020209000801080607-- From nobody Thu Apr 14 05:12:34 2016 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 A0B8F12DDCA; Thu, 14 Apr 2016 05:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 mZFSw3FKYKZI; Thu, 14 Apr 2016 05:06:31 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F9112DBB6; Thu, 14 Apr 2016 05:06:31 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3EC41pp022486; Thu, 14 Apr 2016 08:06:16 -0400 Received: from vawvcgsie2k1302.ciena.com (lin1-118-36-36.ciena.com [63.118.36.36]) by mx0a-00103a01.pphosted.com with ESMTP id 22aauur0rv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 14 Apr 2016 08:06:15 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by VAWVCGSIE2K1302.ciena.com (10.4.62.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 08:06:14 -0400 Received: from ONWVEXCHMB03.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Thu, 14 Apr 2016 08:06:13 -0400 From: "Ranganathan, Raghu" To: Benoit Claise , Liaison Statement Management Tool , "ietf@wjcerveny.com" , "joelja@bogus.com" , "adrian@olddog.co.uk" , "rcallon@juniper.net" , "ietf@trammell.ch" , "swallow.ietf@gmail.com" , "bill.wu@huawei.com" , "loa@pi.nu" Date: Thu, 14 Apr 2016 08:06:11 -0400 Thread-Topic: New Liaison Statement, "Liaison from MEF on IP Service Attributes" Thread-Index: AdGWPEUQ+cgXtqgnRCi+qLjmB7N2hwACYRmw Message-ID: <679E55ADEABC9443947F5AD6F3ED464A21C0BA0E3A@ONWVEXCHMB03.ciena.com> References: <20160226180541.18278.30437.idtracker@ietfa.amsl.com> <570F774B.1080907@cisco.com> In-Reply-To: <570F774B.1080907@cisco.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-22258.006 x-tm-as-result: No--48.009100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_679E55ADEABC9443947F5AD6F3ED464A21C0BA0E3AONWVEXCHMB03c_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-14_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604140173 Archived-At: X-Mailman-Approved-At: Thu, 14 Apr 2016 05:12:33 -0700 Cc: L3VPN Service Model Discussion List , Multiprotocol Label Switching Discussion List , Deborah Brungard , IP Performance Metrics Discussion List , Bill Bjorkman , Nan Chen , Alia Atlas , Martin Stiemerling , The IETF Chair , Spencer Dawkins , Alvaro Retana Subject: Re: [L3sm] New Liaison Statement, "Liaison from MEF on IP Service Attributes" X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 12:06:35 -0000 --_000_679E55ADEABC9443947F5AD6F3ED464A21C0BA0E3AONWVEXCHMB03c_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVub2l0DQpUaGFua3MuIEkgd2lsbCBwb3N0IHRoaXMgdG8gdGhlIGF0dGVudGlvbiBvZiBvdXIg bWVtYmVycyBmb3IgcmV2aWV3IGR1cmluZyB0aGUgdXBjb21pbmcgUTIgbWVldGluZyBpbiBSb21l LCBJdGFseSAoQXByaWwgMjUtMjgpLg0KLS1SYWdodQ0KDQpGcm9tOiBCZW5vaXQgQ2xhaXNlIFtt YWlsdG86YmNsYWlzZUBjaXNjby5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTQsIDIwMTYg NTo1NiBBTQ0KVG86IExpYWlzb24gU3RhdGVtZW50IE1hbmFnZW1lbnQgVG9vbDsgaWV0ZkB3amNl cnZlbnkuY29tOyBqb2VsamFAYm9ndXMuY29tOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyByY2FsbG9u QGp1bmlwZXIubmV0OyBpZXRmQHRyYW1tZWxsLmNoOyBzd2FsbG93LmlldGZAZ21haWwuY29tOyBi aWxsLnd1QGh1YXdlaS5jb207IGxvYUBwaS5udQ0KQ2M6IFJhbmdhbmF0aGFuLCBSYWdodTsgSVAg UGVyZm9ybWFuY2UgTWV0cmljcyBEaXNjdXNzaW9uIExpc3Q7IE11bHRpcHJvdG9jb2wgTGFiZWwg U3dpdGNoaW5nIERpc2N1c3Npb24gTGlzdDsgTmFuIENoZW47IEwzVlBOIFNlcnZpY2UgTW9kZWwg RGlzY3Vzc2lvbiBMaXN0OyBTcGVuY2VyIERhd2tpbnM7IE1hcnRpbiBTdGllbWVybGluZzsgQmls bCBCam9ya21hbjsgQWxpYSBBdGxhczsgVGhlIElFVEYgQ2hhaXI7IERlYm9yYWggQnJ1bmdhcmQ7 IEFsdmFybyBSZXRhbmENClN1YmplY3Q6IFJlOiBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJMaWFp c29uIGZyb20gTUVGIG9uIElQIFNlcnZpY2UgQXR0cmlidXRlcyINCg0KRGVhciBhbGwsDQoNClRo ZSBMM1NNLCBJUFBNLCBNUExTLCBhbmQgdGhlIE9QUyBBcmVhIHdvdWxkIGxpa2UgdG8gdGhhbmsg dGhlIE1FRiBmb3IgaW5mb3JtaW5nIHVzIG9mIHlvdXIgZWZmb3J0IG9uIElQIFNlcnZpY2UgQXR0 cmlidXRlczxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTQ1OC8+ICBbMV0u DQoNCldlJ3JlIHBsZWFzZWQgdGhhdCB5b3UgbWVudGlvbmVkIHRoZSBMM1ZQTiBzZXJ2aWNlIG1v ZGVsIChMM1NNKSB3b3JrIGluIHlvdXIgbGlhaXNvbi4gVGhlIEwzU00gd29yayBjb3ZlcnMgYW4g YWJzdHJhY3RlZCB2aWV3IG9mIHRoZSBMYXllciAzIElQVlBOIHNlcnZpY2UgY29uZmlndXJhdGlv biBjb21wb25lbnRzLCB3aXRoIGl0cyAiWUFORyBEYXRhIE1vZGVsIGZvciBMM1ZQTiBzZXJ2aWNl IGRlbGl2ZXJ5IiBbMl0gZGVsaXZlcmFibGUuDQoNCkZyb20geW91ciBsaWFpc29uIHN0YXRlbWVu dCwgd2UgcmVhZCAiSW4gTUVGIHRlcm1zLCBhICJzZXJ2aWNlIiByZWZlcnMgdG8gdGhlIHNldCBv ZiBhdHRyaWJ1dGVzIGFuZCB0aGVpciB2YWx1ZXMgdGhhdCBhcmUgYWdyZWVkIGJldHdlZW4gdGhl IHByb3ZpZGVyIG9mIGEgc2VydmljZSBhbmQgdGhlIGN1c3RvbWVyIG9mIHRoYXQgc2VydmljZS4i IFlvdSB3aWxsIGJlIGdsYWQgdG8gaGVhciB0aGF0IHdlIHVzZSB0aGUgc2FtZSBkZWZpbml0aW9u IGluIG91ciBMM1NNIHdvcmsuIEFzIHN1Y2gsIHRoZSBNRUYgaW5pdGlhdGl2ZSBvbiBJUCBzZXJ2 aWNlIGF0dHJpYnV0ZXMgY2xlYXJseSByZWxhdGVzIHRvIEwzU00uDQoNClRoZSBMM1NNIGNoYWly cyBhbmQgd29ya2luZyBncm91cCBoYXZlIGV4YW1pbmVkIHRoZSBwcm9wb3NlZCBzY29wZSBvZiB0 aGUgaW5pdGlhbCBwaGFzZSBvZiB0aGUgTUVGIElQIFNlcnZpY2UgQXR0cmlidXRlcyBwcm9qZWN0 Og0KLURlZmluaXRpb24gb2YgYXR0cmlidXRlcyBmb3IgSVAtY2FwYWJsZSBVTklzIGFuZCBOTklz LCBmb3IgSVAgU2VydmljZSBjb25uZWN0aW9ucywgYW5kIGZvciBJUCBTZXJ2aWNlIEVuZCBQb2lu dHMgYXQgVU5JcyBhbmQgRU5OSXMNCi1JUCBhZGRyZXNzIGFsbG9jYXRpb25zIGFuZCBJUCBjb250 cm9sIHByb3RvY29scyAoZS5nLiBESENQKSBldGMgYXQgVU5Jcw0KLU9BTSBhY3Jvc3MgdGhlIGV4 dGVybmFsIGludGVyZmFjZSAoYnkgcmVmZXJlbmNlIHRvIElFVEYgcHJvdG9jb2xzIGFuZA0KbWVj aGFuaXNtcykNCi1TZXJ2aWNlIExldmVsIFNwZWNpZmljYXRpb24gKFNMUykgZGVmaW5pdGlvbnMg aW5jbHVkaW5nIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcvY29uc3RyYWludHMgKGJ5IHJlZmVyZW5j ZSB0byBJRVRGIHByb3RvY29scyBhbmQgbWV0cmljIGRlZmluaXRpb25zKQ0KLVJlZHVuZGFudCBs aW5rcyBhdCBhbiBleHRlcm5hbCBpbnRlcmZhY2UgKFN1YnNjcmliZXIvU2VydmljZSBwcm92aWRl ciBvciBiZXR3ZWVuIFNlcnZpY2UgUHJvdmlkZXJzKSwgaW5jbHVkaW5nIG9wdGlvbnMgZm9yIGRp ZmZlcmVudCByb3V0aW5nIHByb3RvY29scy4NCi1NdWx0aS1Db1Mgc2VydmljZXMgKGkuZS4gUW9T IGNsYXNzaWZpY2F0aW9uKSBhbmQgY2xhc3NpZmljYXRpb24gb2YNCkdyZWVuL1llbGxvdyBwYWNr ZXRzIGluY2x1ZGluZyBkaWZmc2VydiwgQmFuZHdpZHRoIHByb2ZpbGVzLCBldGMuDQotSVB2NCwg SVB2NiBhbmQgZHVhbCBzdGFjayBzZXJ2aWNlcw0KLUludGVyLW9wZXJhdG9yIElQLVZQTiBzZXJ2 aWNlcyB1c2luZyBvcHRpb25zIEEsIEIgb3IgQyBmcm9tIFJGQzQzNjQNCi1VbmljYXN0IG9ubHkg KG11bHRpY2FzdCBpcyBkZWZlcmVkIHRvIGEgZnV0dXJlIHBoYXNlKS4NCi1PdGhlciB0b3BpY3Mg bWF5IGJlIGFkZGVkIGFzIHRoZSBwcm9qZWN0IHByb2dyZXNzZXMuDQoNClRoZSBMM1NNIHdvcmsg YWxyZWFkeSBjb3ZlcnMgbW9zdCBvZiB0aGUgaXRlbXMgaW4gdGhpcyBsaXN0LCBpbmNsdWRpbmcg bXVsdGljYXN0LiAgSG93ZXZlciwgd2Ugc2hvdWxkIG9ic2VydmUgdGhhdDoNCjEuICBMM1NNIGhh cyBpbml0aWFsbHkgZm9jdXNlZCBvbiB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIGN1c3RvbWVy IGFuZCB0aGUgc2VydmljZSBwcm92aWRlciwgbm90IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBzZXJ2 aWNlcyBwcm92aWRlcnMgb3IgYmV0d2VlbiBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbnMuIFRoZSBj dXJyZW50IHNlcnZpY2UgbW9kZWwgc3VwcG9ydHMgdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIFJG QyA0MzY0IG9wdGlvbiBBIChhcyB0aGlzIGlzIGEgc3Vic2V0IG9mIHRoZSBleGlzdGluZyBzaXRl IG1vZGVsKSwgYW5kIHdlJ3JlIGNvbnNpZGVyaW5nIHdoZXRoZXIgdG8gYWRkIG9wdGlvbiBCIGFu ZCBDLg0KMi4gIFRoZSBMM1NNIHdvcmsgZG9lcyBub3QgY292ZXIgZWl0aGVyIHRoZSBTZXJ2aWNl IExldmVsIFNwZWNpZmljYXRpb24gZGVmaW5pdGlvbnMgb3IgdGhlIExpZmVjeWNsZSBTZXJ2aWNl IE9yY2hlc3RyYXRpb24gYXMgZGVzY3JpYmVkIGluIHRoZSBNRUYgTGlmZWN5Y2xlIFNlcnZpY2Ug T3JjaGVzdHJhdGlvbiAoTFNPKSBSZWZlcmVuY2UgQXJjaGl0ZWN0dXJlICYgRnJhbWV3b3JrLg0K DQpUaGUgTDNTTSB3b3JrIHN0YXJ0ZWQgYWJvdXQgYSB5ZWFyIGFnbyBhbmQgaXMgaW4gdGhlIGZp bmFsIHN0YWdlIG9mIHN0YW5kYXJkaXphdGlvbi4gVGhlcmVmb3JlLCB3ZSB3b3VsZCBlbmNvdXJh Z2UgYW55b25lIHdobyBpcyBpbnRlcmVzdGVkIHRvIHJldmlldyBhbmQgcHJvdmlkZSBmZWVkYmFj ayBvbiB0aGUgZnV0dXJlIHN0YW5kYXJkIGJ5IHNlbmRpbmcgYSBtZXNzYWdlIHRvIHRoZSBMM1NN IG1haWxpbmcgbGlzdCBhcyBzb29uIGFzIHBvc3NpYmxlIChkZXRhaWxzIGF0IFszXSkuIFBsZWFz ZSBrZWVwIHVzIGluZm9ybWVkIG9mIGFueSBnYXBzIHlvdSBpZGVudGlmeSB0aGF0IGFyZSBuZWVk ZWQgdG8gc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnRzIGluIHlvdXIgc3BlY2lmaWNhdGlvbnMsIHdp dGhvdXQgdGhlIG5lZWQgZm9yIGEgZm9ybWFsIGxpYWlzb24uDQoNCkkgaG9wZSB5b3Ugd2lsbCBh Z3JlZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBub3QgZHVwbGljYXRlIHdvcmsgd2l0aGluIHN0 YW5kYXJkaXphdGlvbi4gVGhlcmVmb3JlLCBJIGhvcGUgeW91IHdpbGwgd29yayB0byBwcm9kdWNl IGV4dGVuc2lvbnMgdG8gdGhlIEwzU00gWUFORyBtb2RlbCBmb3IgYWRkaXRpb25hbCBmZWF0dXJl cyBzdWNoIGFzIHRoZSBTZXJ2aWNlIExldmVsIFNwZWNpZmljYXRpb24sIGFuZCB3aWxsIG5vdCBy ZXBlYXQgYW55IG9mIHRoZSBmdW5jdGlvbiBhbHJlYWR5IHByb3ZpZGVkIGJ5IHRoYXQgbW9kZWwu IElmIHlvdSBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIGRvbid0IGhlc2l0YXRlIHRvIGNvbnRh Y3QgdXMuIFdlIGFyZSBhbHdheXMgYXZhaWxhYmxlIGZvciBmdXJ0aGVyIGRpc2N1c3Npb25zIG9y IGNvbmZlcmVuY2UgY2FsbHMgcmVnYXJkaW5nIHRoZSBMM1NNIHNwZWNpZmljYXRpb25zIGNvbnRl bnQuDQoNClJlZ2FyZHMsIEJlbm9pdCBDbGFpc2UgKE9QUyBBcmVhIERpcmVjdG9yKQ0KDQpbMV0g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE0NTgvDQpbMl0gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9k ZWwvDQpbM10gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9sM3NtL2NoYXJ0ZXIvDQoN Cg0KDQpUaXRsZTogTGlhaXNvbiBmcm9tIE1FRiBvbiBJUCBTZXJ2aWNlIEF0dHJpYnV0ZXMNCg0K U3VibWlzc2lvbiBEYXRlOiAyMDE2LTAyLTI2DQoNClVSTCBvZiB0aGUgSUVURiBXZWIgcGFnZTog aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE0NTgvDQoNCg0KDQpGcm9tOiAi UmFnaHUgUmFuZ2FuYXRoYW4iIDxycmFnaHVAY2llbmEuY29tPjxtYWlsdG86cnJhZ2h1QGNpZW5h LmNvbT4NCg0KVG86IGJjbGFpc2VAY2lzY28uY29tPG1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbT4s IGpvZWxqYUBib2d1cy5jb208bWFpbHRvOmpvZWxqYUBib2d1cy5jb20+LCBpZXRmQHRyYW1tZWxs LmNoPG1haWx0bzppZXRmQHRyYW1tZWxsLmNoPj4sIGlldGZAd2pjZXJ2ZW55LmNvbTxtYWlsdG86 aWV0ZkB3amNlcnZlbnkuY29tPiwgbG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+LCBzd2FsbG93 LmlldGZAZ21haWwuY29tPG1haWx0bzpzd2FsbG93LmlldGZAZ21haWwuY29tPiwgcmNhbGxvbkBq dW5pcGVyLm5ldDxtYWlsdG86cmNhbGxvbkBqdW5pcGVyLm5ldD4sIGFkcmlhbkBvbGRkb2cuY28u dWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+LCBiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRv OmJpbGwud3VAaHVhd2VpLmNvbT4NCg0KQ2M6IEFsdmFybyBSZXRhbmEgPGFyZXRhbmFAY2lzY28u Y29tPjxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+LEpvZWwgSmFlZ2dsaSA8am9lbGphQGJvZ3Vz LmNvbT48bWFpbHRvOmpvZWxqYUBib2d1cy5jb20+LERlYm9yYWggQnJ1bmdhcmQgPGRiMzU0NkBh dHQuY29tPjxtYWlsdG86ZGIzNTQ2QGF0dC5jb20+LElQIFBlcmZvcm1hbmNlIE1ldHJpY3MgRGlz Y3Vzc2lvbiBMaXN0IDxpcHBtQGlldGYub3JnPjxtYWlsdG86aXBwbUBpZXRmLm9yZz4sTXVsdGlw cm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgRGlzY3Vzc2lvbiBMaXN0IDxtcGxzQGlldGYub3JnPjxt YWlsdG86bXBsc0BpZXRmLm9yZz4sQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az48 bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+LFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPjxt YWlsdG86YmlsbC53dUBodWF3ZWkuY29tPixCaWxsIENlcnZlbnkgPGlldGZAd2pjZXJ2ZW55LmNv bT48bWFpbHRvOmlldGZAd2pjZXJ2ZW55LmNvbT4sQnJpYW4gVHJhbW1lbGwgPGlldDxtYWlsdG86 aWV0ZkB0cmFtbWVsbC5jaD4NCg0KZkB0cmFtbWVsbC5jaD48bWFpbHRvOmlldGZAdHJhbW1lbGwu Y2g+LFNwZW5jZXIgRGF3a2lucyA8c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+PG1haWx0 bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4sR2VvcmdlIFN3YWxsb3cgPHN3YWxsb3cu aWV0ZkBnbWFpbC5jb20+PG1haWx0bzpzd2FsbG93LmlldGZAZ21haWwuY29tPixBbGlhIEF0bGFz IDxha2F0bGFzQGdtYWlsLmNvbT48bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPixUaGUgSUVURiBD aGFpciA8Y2hhaXJAaWV0Zi5vcmc+PG1haWx0bzpjaGFpckBpZXRmLm9yZz4sTmFuIENoZW4gPG5h bkBtZXRyb2V0aGVybmV0Zm9ydW0ub3JnPjxtYWlsdG86bmFuQG1ldHJvZXRoZXJuZXRmb3J1bS5v cmc+LFJvc3MgQ2FsbG9uIDxyY2FsbG9uQGp1bmlwZXIubmV0PjxtYWlsdG86cmNhbGxvbkBqdW5p cGVyLm5ldD4sTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PjxtYWlsdG86bG9hQHBpLm51PixCZW5v aXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT48bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPixM M1ZQTiBTZXJ2aWNlIE1vZGVsICBEaXNjdXNzaW9uIExpc3QgPGwzc21AaWV0Zi5vcmc+PG1haWx0 bzpsM3NtQGlldGYub3JnPixCaWxsIEJqb3JrbWFuIDxiaWxsQG1ldHJvZXRoZXJuZXRmb3J1bS5u ZXQ+PG1haWx0bzpiaWxsQG1ldHJvZXRoZXJuZXRmb3J1bS5uZXQ+LE1hcnRpbiBTdGllbWVybGlu ZyA8bWxzLmlldGZAZ21haWwuY29tPjxtYWlsdG86bWxzLmlldGZAZ21haWwuY29tPixSYWdodSBS YW5nYW5hdGhhbiA8cnJhZ2h1QGNpZW5hLmNvbT48bWFpbHRvOnJyYWdodUBjaWVuYS5jb20+LA0K DQpSZXNwb25zZSBDb250YWN0czogcnJhZ2h1QGNpZW5hLmNvbTxtYWlsdG86cnJhZ2h1QGNpZW5h LmNvbT4NCg0KVGVjaG5pY2FsIENvbnRhY3RzOg0KDQpQdXJwb3NlOiBGb3IgaW5mb3JtYXRpb24N Cg0KDQoNCkJvZHk6IFdlIHdvdWxkIGxpa2UgdG8gaW5mb3JtIHlvdSB0aGF0IGR1cmluZyBvdXIg MVEyMDE2IG1lZXRpbmcsIE1FRiBoYXMgYXBwcm92ZWQgYSBuZXcgcHJvamVjdCBvbiBJUCBTZXJ2 aWNlIEF0dHJpYnV0ZXMuIFdlIGhhdmUgc2V0IG91dCBzb21lIGJhY2tncm91bmQgYW5kIGZ1cnRo ZXIgZGV0YWlscyBiZWxvdy4NCg0KDQoNCk1FRiBpcyB3ZWxsIGtub3duIGZvciB0aGUgZGVmaW5p dGlvbiBvZiBDYXJyaWVyIEV0aGVybmV0IChDRSkgc2VydmljZXMgKGluIE1FRiA2LjIsIE1FRiAz MyBhbmQgTUVGIDUxKSBiYXNlZCBvbiBzZXJ2aWNlIGF0dHJpYnV0ZXMgKGRlZmluZWQgaW4gTUVG IDEwLjMgYW5kIE1FRiAyNi4xKS4gSW4gTUVGIHRlcm1zLCBhICJzZXJ2aWNlIiByZWZlcnMgdG8g dGhlIHNldCBvZiBhdHRyaWJ1dGVzIGFuZCB0aGVpciB2YWx1ZXMgdGhhdCBhcmUgYWdyZWVkIGJl dHdlZW4gdGhlIHByb3ZpZGVyIG9mIGEgc2VydmljZWFuZCB0aGUgY3VzdG9tZXIgb2YgdGhhdCBz ZXJ2aWNlLiBUaGVzZSBhdHRyaWJ1dGVzIGFyZSBpbmRlcGVuZGVudCBvZiBob3cgdGhlIHNlcnZp Y2UgaXMgaW1wbGVtZW50ZWQ7IGZvciBleGFtcGxlIGEgQ0Ugc2VydmljZSBjb3VsZCBiZQ0KDQpp bXBsZW1lbnRlZCB1c2luZyBQcm92aWRlciBCYWNrYm9uZSBCcmlkZ2luZyAoODAyLjFRKSBvciB1 c2luZyBWUExTIChSRkMgNDc2MS80NzYyKSB0byBwcm92aWRlIHRoZSBjb25uZWN0aXZpdHkgYWNy b3NzIHRoZSBzZXJ2aWNlIHByb3ZpZGVyJ3MgbmV0d29yay4gTUVGIGRlZmluZXMgYm90aCBlbmQt dG8tZW5kIHNlcnZpY2VzIGFncmVlZCBiZXR3ZWVuIGEgc3Vic2NyaWJlciBhbmQgYSBzZXJ2aWNl IHByb3ZpZGVyLCB3aGVyZSB0aGUgZW5kIHBvaW50cyBhcmUgYWxsIFVzZXItTmV0d29yayBJbnRl cmZhY2VzIChVTklzKSwgYW5kIGludGVyLXByb3ZpZGVyIHNlcnZpY2VzIHN1cHBsaWVkIGJ5IG9u ZSBzZXJ2aWNlIHByb3ZpZGVyIG9yIG9wZXJhdG9yIHRvIGFub3RoZXIsIHdoZXJlIHRoZSBlbmQg cG9pbnRzIG1heSBiZSBVTklzIG9yIEV4dGVybmFsIE5ldHdvcmstTmV0d29yayBJbnRlcmZhY2Vz IChFTk5JcykuDQoNCg0KDQpOb3RlIHRoYXQgdGhpcyBkaWZmZXJzIGZyb20gaG93IHRoZSB3b3Jk ICJzZXJ2aWNlIiBpcyBzb21ldGltZXMgdXNlZCBpbiBJRVRGLCBlLmcuIHRvIGRlc2NyaWJlIGEg cGFydGljdWxhciB0ZWNobm9sb2d5IChhcyBpbiAiVmlydHVhbCBQcml2YXRlIExBTiBTZXJ2aWNl IikuDQoNCg0KDQpBbHRob3VnaCBJUCBTZXJ2aWNlcyBhcmUgd2lkZWx5IGRlcGxveWVkLCB0aGVy ZSBpcyBjdXJyZW50bHkgbm8gc3RhbmRhcmQgZGVmaW5pdGlvbiBvZiB0aGUgYXR0cmlidXRlcyBh bmQgdmFsdWVzIHVzZWQgdG8gZGVzY3JpYmUgdGhlbS4gRWFjaCBTZXJ2aWNlIFByb3ZpZGVyIGhh cyB0aGVpciBvd24gd2F5IG9mIGRlc2NyaWJpbmcgSVAgc2VydmljZXMgKGluY2x1ZGluZyBpbiBz b21lIGNhc2VzIHRoZWlyIG93biB0ZXJtaW5vbG9neSk7IHRoaXMgbWFrZXMgaXQgaGFyZCBmb3Ig Y3VzdG9tZXJzIHRvIGNvbXBhcmUgc2VydmljZSBvZmZlcmluZ3MgZnJvbSBkaWZmZXJlbnQgcHJv dmlkZXJzLCBhbmQgaW4gcGFydGljdWxhciBtYWtlcyBpdCBoYXJkIGZvciBwcm92aWRlcnMgdG8g aW50ZXJjb25uZWN0IHdpdGggZWFjaCBvdGhlciDigJMgZWFjaCBTZXJ2aWNlIFByb3ZpZGVyIG11 c3QgZm9ybSBhIHNwZWNpZmljIGJpbGF0ZXJhbCBhZ3JlZW1lbnQgd2l0aCBlYWNoIG90aGVyIFNl cnZpY2UgUHJvdmlkZXIgdGhleSB3aXNoIHRvIGNvbm5lY3Qgd2l0aC4NCg0KDQoNCkZ1cnRoZXJt b3JlLCB0aGVyZSBpcyBhIGRlc2lyZSBhbW9uZyBzZXJ2aWNlIHByb3ZpZGVycyB0byBpbXByb3Zl IHNlcnZpY2UgZGVsaXZlcnkgdGltZXMgYnkgYXV0b21hdGluZyB0aGUgc2VydmljZSBvcmRlcmlu ZyBhbmQgY29uZmlndXJhdGlvbiBwcm9jZXNzLiBUaGlzIGlzIGEga2V5IGFzcGVjdCBvZiBNRUYg TGlmZWN5Y2xlIFNlcnZpY2VzIE9yY2hlc3RyYXRpb24gKExTTykuIFRoZSBhaW0gb2YgTUVGIExT TyBpcyB0byBkZWxpdmVyIHRoZSBNRUYgVGhpcmQgTmV0d29yayB2aXNpb24sIHRvIHByb3ZpZGUg QXNzdXJlZCwgQWdpbGUgYW5kIE9yY2hlc3RyYXRlZCBzZXJ2aWNlcy4gTUVGIExTTyBlbmFibGVz IGF1dG9tYXRpb24gYW5kIG9yY2hlc3RyYXRpb24gb2Ygc2VydmljZSBvcmRlcmluZyBhbmQgbWFu YWdlbWVudCBiZXR3ZWVuIHNlcnZpY2UgcHJvdmlkZXJzICgiRWFzdC9XZXN0IGludGVyZmFjZXMi KSB0aHJvdWdoIHRoZSBjcmVhdGlvbiBvZiBzdGFuZGFyZCBkYXRhIG1vZGVscyBhbmQgQVBJcy4g SG93ZXZlciwgYSBwcmUtcmVxdWlzaXRlIGZvciBkZWZpbmluZyB0aG9zZSBpcyB0byBoYXZlIGEg c3RhbmRhcmQgZGVmaW5pdGlvbiBvZiB0aGUgc2VydmljZSB0aGF0IGlzIHRvIGJlIG1hbmFnZWQu DQoNCg0KDQpUaGUgbmV3IHByb2plY3QgaXMgaW50ZW5kZWQgdG8gYWRkcmVzcyB0aGVzZSBpc3N1 ZXMgYnkgcHJvdmlkaW5nIGEgc3RhbmRhcmQgZGVmaW5pdGlvbiBvZiBJUCBTZXJ2aWNlcywgaW5j bHVkaW5nIGJvdGggZW5kLXRvLWVuZCBzZXJ2aWNlcyBhbmQgaW50ZXItcHJvdmlkZXIgc2Vydmlj ZXMsIHRocm91Z2ggdGhlIGRlZmluaXRpb24gb2YgYSBzdGFuZGFyZCBzZXQgb2YgU2VydmljZSBB dHRyaWJ1dGVzIHRoYXQgY2FuIGJlIHVzZWQgaW4gZWFjaCBjYXNlLiBUaGUgc2NvcGUgaXMgbGlt aXRlZCB0byBJUC1WUE4gYW5kIEludGVybmV0IEFjY2VzcyBzZXJ2aWNlcyAgKElQIHBlZXJpbmcv dHJhbnNpdCBmb3IgaW50ZXJuZXQgdHJhZmZpYyBpcyBwcmVjbHVkZWQpLiBJdCBpcyBpbnRlbmRl ZCB0aGF0IHRoaXMgcHJvamVjdCBpcyB0aGUgZmlyc3Qgc3RlcCBpbiBlbmFibGluZyBtdWx0aS1v cGVyYXRvciBzZXJ2aWNlIG9yY2hlc3RyYXRpb24gb2YgSVAgU2VydmljZXMgdXNpbmcgTUVGIExT TywgYW5kIHRoYXQgbGF0ZXIgcHJvamVjdHMgd2lsbCB1c2UgdGhlIFNlcnZpY2UgQXR0cmlidXRl cyB0byBjcmVhdGUgc3RhbmRhcmQgZGF0YSBtb2RlbHMgYW5kIEFQSXMuIFRoZSBpbnRlbnQgb2Yg TFNPIGlzIHRvIHByb3ZpZGUgYSBjb21tb24gZnJhbWV3b3JrIGFjcm9zcyBkaWZmZXJlbnQgc2Vy dmljZSB0ZWNobm9sb2dpZXM7IE1FRiBpcyB3b3JraW5nIHdpdGggVE1GIGFuZCBPTkYgdG8gY3Jl YXRlIGNvbW1vbiBtb2RlbHMgZm9yIHNlcnZpY2VzLCBhbmQgdGhlIHN0YW5kYXJkIGRhdGEgbW9k ZWxzIGFuZCBBUElzIGZvciBJUCBTZXJ2aWNlcyB3aWxsIHRpZSBpbnRvIHRoaXMgZnJhbWV3b3Jr Lg0KDQoNCg0KV2UgaGF2ZSBub3RlZCB0aGF0IElFVEYgaXMgd29ya2luZyBvbiBhIFlhbmcgbW9k ZWwgZm9yIExheWVyIDMgU2VydmljZXMgaW4gdGhlIEwzU00gd29ya2luZyBncm91cC4gQWx0aG91 Z2ggdGhlIHNjb3BlIG9mIHRoYXQgcHJvamVjdCBpbiBJRVRGIGlzIGRpZmZlcmVudCwgaXQgaXMg Y2xlYXIgdGhlcmUgaXMgc29tZSBzeW5lcmd5IGJldHdlZW4gdGhlIEwzU00gd29yayBhbmQgdGhp cyBNRUYgcHJvamVjdC4gV2UgYmVsaWV2ZSB0aGF0IGJvdGggcHJvamVjdHMgY2FuIGJlbmVmaXQg ZnJvbSBpbnB1dCBmcm9tIGVhY2ggb3RoZXIgYW5kIHdlIGhvcGUgdG8gd29yayBjbG9zZWx5IHdp dGggdGhlIEwzU00gd29ya2luZyBncm91cCB0byBlbnN1cmUgb3VyIHNwZWNpZmljYXRpb25zIGFy ZSBhbGlnbmVkLg0KDQoNCg0KVGhlIHNjb3BlIG9mIHRoZSBpbml0aWFsIHBoYXNlIG9mIHRoZSBJ UCBTZXJ2aWNlIEF0dHJpYnV0ZXMgcHJvamVjdCBpbmNsdWRlczoNCg0KLURlZmluaXRpb24gb2Yg YXR0cmlidXRlcyBmb3IgSVAtY2FwYWJsZSBVTklzIGFuZCBOTklzLCBmb3IgSVAgU2VydmljZSBj b25uZWN0aW9ucywgYW5kIGZvciBJUCBTZXJ2aWNlIEVuZCBQb2ludHMgYXQgVU5JcyBhbmQgRU5O SXMNCg0KLUlQIGFkZHJlc3MgYWxsb2NhdGlvbnMgYW5kIElQIGNvbnRyb2wgcHJvdG9jb2xzIChl LmcuIERIQ1ApIGV0YyBhdCBVTklzDQoNCi1PQU0gYWNyb3NzIHRoZSBleHRlcm5hbCBpbnRlcmZh Y2UgKGJ5IHJlZmVyZW5jZSB0byBJRVRGIHByb3RvY29scyBhbmQgbWVjaGFuaXNtcykNCg0KLVNl cnZpY2UgTGV2ZWwgU3BlY2lmaWNhdGlvbiAoU0xTKSBkZWZpbml0aW9ucyBpbmNsdWRpbmcgcGVy Zm9ybWFuY2UgbW9uaXRvcmluZy9jb25zdHJhaW50cyAoYnkgcmVmZXJlbmNlIHRvIElFVEYgcHJv dG9jb2xzIGFuZCBtZXRyaWMgZGVmaW5pdGlvbnMpDQoNCi1SZWR1bmRhbnQgbGlua3MgYXQgYW4g ZXh0ZXJuYWwgaW50ZXJmYWNlIChTdWJzY3JpYmVyL1NlcnZpY2UgcHJvdmlkZXIgb3IgYmV0d2Vl biBTZXJ2aWNlIFByb3ZpZGVycyksIGluY2x1ZGluZyBvcHRpb25zIGZvciBkaWZmZXJlbnQgcm91 dGluZyBwcm90b2NvbHMuDQoNCi1NdWx0aS1Db1Mgc2VydmljZXMgKGkuZS4gUW9TIGNsYXNzaWZp Y2F0aW9uKSBhbmQgY2xhc3NpZmljYXRpb24gb2YgR3JlZW4vWWVsbG93IHBhY2tldHMgaW5jbHVk aW5nIGRpZmZzZXJ2LCBCYW5kd2lkdGggcHJvZmlsZXMsIGV0Yy4NCg0KLUlQdjQsIElQdjYgYW5k IGR1YWwgc3RhY2sgc2VydmljZXMNCg0KLUludGVyLW9wZXJhdG9yIElQLVZQTiBzZXJ2aWNlcyB1 c2luZyBvcHRpb25zIEEsIEIgb3IgQyBmcm9tIFJGQzQzNjQNCg0KLVVuaWNhc3Qgb25seSAobXVs dGljYXN0IGlzIGRlZmVyZWQgdG8gYSBmdXR1cmUgcGhhc2UpLg0KDQotT3RoZXIgdG9waWNzIG1h eSBiZSBhZGRlZCBhcyB0aGUgcHJvamVjdCBwcm9ncmVzc2VzLg0KDQoNCg0KSXQgaXMgaW1wb3J0 YW50IHRvIG5vdGUgdGhhdCB3ZSBpbnRlbmQgdG8gbWFrZSBleHRlbnNpdmUgcmVmZXJlbmNlIHRv IGV4aXN0aW5nIElFVEYgUkZDcyB3aGVyZSBhcHBsaWNhYmxlOyBpdCBpcyBub3Qgb3VyIGludGVu dCB0byBzcGVjaWZ5IG5ldyBwcm90b2NvbHMgb3IgbWVjaGFuaXNtcyB3aGVyZSB0aGVyZSBhcmUg ZXhpc3Rpbmcgc29sdXRpb25zLg0KDQoNCg0KTm90ZTogZnVydGhlciBpbmZvcm1hdGlvbiBhYm91 dCBNRUYgTFNPIGNhbiBiZSBmb3VuZCBpbiB0aGUgTFNPIFJlZmVyZW5jZSBBcmNoaXRlY3R1cmUu IFRoZSBmaW5hbCB2ZXJpc29uIGlzIGV4cGVjdGVkIHRvIGJlIHB1Ymxpc2hlZCBpbiBNYXJjaDsg aW4gdGhlIG1lYW50aW1lLCB0aGUgbGF0ZXN0IGFwcHJvdmVkIGRyYWZ0IGlzIGF2YWlsYWJsZSBh cyBiZWxvdzoNCg0KaHR0cHM6Ly9tZWYubmV0L2xpYWlzb24tbG9naW4NCg0KVXNlcm5hbWU6IG1l Zg0KDQpBdHRhY2htZW50czoNCg0KDQoNCiAgICBMaWFpc29uDQoNCiAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE2LTAyLTI2LW1lZi1p cHBtLW1wbHMtbDNzbS1vcHMtbGlhaXNvbi1mcm9tLW1lZi1vbi1pcC1zZXJ2aWNlLWF0dHJpYnV0 ZXMtYXR0YWNobWVudC0xLnBkZg0KDQoNCg0KLg0KDQoNCg0K --_000_679E55ADEABC9443947F5AD6F3ED464A21C0BA0E3AONWVEXCHMB03c_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPVByb2dJZCBjb250ZW50PVdv cmQuRG9jdW1lbnQ+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQg MTQiPjxtZXRhIG5hbWU9T3JpZ2luYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCI+PGxp bmsgcmVsPUZpbGUtTGlzdCBocmVmPSJjaWQ6ZmlsZWxpc3QueG1sQDAxRDE5NjFDLjIwN0U2NEUw Ij48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8 bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6U3BlbGxp bmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0KPHc6R3JhbW1hclN0YXRlPkNsZWFuPC93 OkdyYW1tYXJTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3 OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1M SW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRDb250ZW50 PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRl eHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJvbW90ZVFG Lz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1l QXNpYW4+WC1OT05FPC93OkxpZFRoZW1lQXNpYW4+DQo8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+ WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNjcmlwdD4NCjx3OkNvbXBhdGliaWxpdHk+DQo8dzpE b05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCjx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQo8dzpTcGxp dFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpFbmFibGVPcGVuVHlwZUtlcm5pbmcvPg0KPC93OkNv bXBhdGliaWxpdHk+DQo8bTptYXRoUHI+DQo8bTptYXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRo Ii8+DQo8bTpicmtCaW4gbTp2YWw9ImJlZm9yZSIvPg0KPG06YnJrQmluU3ViIG06dmFsPSImIzQ1 Oy0iLz4NCjxtOnNtYWxsRnJhYyBtOnZhbD0ib2ZmIi8+DQo8bTpkaXNwRGVmLz4NCjxtOmxNYXJn aW4gbTp2YWw9IjAiLz4NCjxtOnJNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOmRlZkpjIG06dmFsPSJj ZW50ZXJHcm91cCIvPg0KPG06d3JhcEluZGVudCBtOnZhbD0iMTQ0MCIvPg0KPG06aW50TGltIG06 dmFsPSJzdWJTdXAiLz4NCjxtOm5hcnlMaW0gbTp2YWw9InVuZE92ciIvPg0KPC9tOm1hdGhQcj48 L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8dzpMYXRlbnRTdHlsZXMgRGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBEZWZVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgRGVmU2VtaUhpZGRlbj0idHJ1ZSIgRGVmUUZvcm1hdD0iZmFsc2UiIERlZlBy aW9yaXR5PSI5OSIgTGF0ZW50U3R5bGVDb3VudD0iMjY3Ij4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm9ybWFsIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp bmcgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRv YyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1l PSJ0b2MgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg TmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBOYW1lPSJ0b2MgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgTmFtZT0idG9jIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM1IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJjYXB0aW9uIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBOYW1lPSJEZWZhdWx0 IFBhcmFncmFwaCBGb250Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjExIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIyMiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3Ryb25nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjIwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFj aW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IlJldmlzaW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJMaXN0IFBhcmFncmFwaCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIyOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iUXVvdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUXVvdGUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlz dCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3Qg MSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IExpc3QgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0 IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYy IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBH cmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gU2hhZGluZyAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNo YWRpbmcgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNv bG9yZnVsIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0 IDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBHcmlkIDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5n IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBHcmlkIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTkiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBFbXBo YXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iSW50ZW5zZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIFJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBSZWZlcmVuY2UiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkJvb2sgVGl0 bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzciIE5hbWU9 IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCjwvdzpMYXRlbnRTdHls ZXM+DQo8L3htbD48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAq Lw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1m b250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1z aWduYXR1cmU6LTUzNjg3MDE0NSAxMTA3MzA1NzI3IDAgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJ bXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1z by1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODcwMTQ1IDEw NzM3ODYxMTEgMSAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCglt c28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsN Cgltc28tZm9udC1zaWduYXR1cmU6LTUyMDA4MTY2NSAtMTA3MzcxNzE1NyA0MSAwIDY2MDQ3IDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYg OSAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1m YW1pbHk6bW9kZXJuOw0KCW1zby1mb250LXBpdGNoOmZpeGVkOw0KCW1zby1mb250LXNpZ25hdHVy ZTotNTIwMDkyOTI5IDEwNzM4MDY1OTEgOSAwIDQxNSAwO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHls ZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6 IiI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRp b246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5v c2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KcHJlDQoJe21zby1zdHlsZS1ub3No b3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp Ow0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtbG9ja2VkOnllczsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1hc2NpaS1m b250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1oYW5zaS1mb250LWZhbWlseTpDb25zb2xhczsNCgltc28tYmlkaS1mb250LWZhbWlseTpD b25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1s b2NrZWQ6eWVzOw0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCW1zby1hbnNpLWZv bnQtc2l6ZTo4LjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpUYWhvbWE7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6 VGFob21hOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OlRhaG9tYTsNCgljb2xvcjpibGFjazt9DQpz cGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28t c3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVp bjsNCgltc28tZm9vdGVyLW1hcmdpbjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1h bFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93 YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9z aG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsN Cgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46 MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3 aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBs YW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGUgc3R5bGU9J3RhYi1pbnRlcnZhbDouNWlu Jz48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO2NvbG9yOiMxRjQ5N0QnPkJlbm9pdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMxRjQ5N0QnPlRoYW5rcy4gSSB3aWxsIHBv c3QgdGhpcyB0byB0aGUgYXR0ZW50aW9uIG9mIG91ciBtZW1iZXJzIGZvciByZXZpZXcgZHVyaW5n IHRoZSB1cGNvbWluZyBRMiBtZWV0aW5nIGluIFJvbWUsIEl0YWx5IChBcHJpbCAyNS0yOCkuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7Y29s b3I6IzFGNDk3RCc+LS1SYWdodTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOndp bmRvd3RleHQnPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7Y29sb3I6d2luZG93dGV4dCc+IEJlbm9pdCBDbGFpc2UgW21haWx0 bzpiY2xhaXNlQGNpc2NvLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMTQs IDIwMTYgNTo1NiBBTTxicj48Yj5Ubzo8L2I+IExpYWlzb24gU3RhdGVtZW50IE1hbmFnZW1lbnQg VG9vbDsgaWV0ZkB3amNlcnZlbnkuY29tOyBqb2VsamFAYm9ndXMuY29tOyBhZHJpYW5Ab2xkZG9n LmNvLnVrOyByY2FsbG9uQGp1bmlwZXIubmV0OyBpZXRmQHRyYW1tZWxsLmNoOyBzd2FsbG93Lmll dGZAZ21haWwuY29tOyBiaWxsLnd1QGh1YXdlaS5jb207IGxvYUBwaS5udTxicj48Yj5DYzo8L2I+ IFJhbmdhbmF0aGFuLCBSYWdodTsgSVAgUGVyZm9ybWFuY2UgTWV0cmljcyBEaXNjdXNzaW9uIExp c3Q7IE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIERpc2N1c3Npb24gTGlzdDsgTmFuIENo ZW47IEwzVlBOIFNlcnZpY2UgTW9kZWwgRGlzY3Vzc2lvbiBMaXN0OyBTcGVuY2VyIERhd2tpbnM7 IE1hcnRpbiBTdGllbWVybGluZzsgQmlsbCBCam9ya21hbjsgQWxpYSBBdGxhczsgVGhlIElFVEYg Q2hhaXI7IERlYm9yYWggQnJ1bmdhcmQ7IEFsdmFybyBSZXRhbmE8YnI+PGI+U3ViamVjdDo8L2I+ IFJlOiBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICZxdW90O0xpYWlzb24gZnJvbSBNRUYgb24gSVAg U2VydmljZSBBdHRyaWJ1dGVzJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiInPkRlYXIgYWxsLDxicj48YnI+VGhlIEwzU00sIElQUE0sIE1QTFMsIGFuZCB0aGUgT1BT IEFyZWEgd291bGQgbGlrZSB0byB0aGFuayB0aGUgTUVGIGZvciBpbmZvcm1pbmcgdXMgb2YgeW91 ciBlZmZvcnQgb24gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29u LzE0NTgvIj5JUCBTZXJ2aWNlIEF0dHJpYnV0ZXM8L2E+Jm5ic3A7IFsxXS48YnI+PGJyPldlJ3Jl IHBsZWFzZWQgdGhhdCB5b3UgbWVudGlvbmVkIHRoZSBMM1ZQTiBzZXJ2aWNlIG1vZGVsIChMM1NN KSB3b3JrIGluIHlvdXIgbGlhaXNvbi4gVGhlIEwzU00gd29yayBjb3ZlcnMgYW4gYWJzdHJhY3Rl ZCB2aWV3IG9mIHRoZSBMYXllciAzIElQVlBOIHNlcnZpY2UgY29uZmlndXJhdGlvbiBjb21wb25l bnRzLCB3aXRoIGl0cyAmcXVvdDtZQU5HIERhdGEgTW9kZWwgZm9yIEwzVlBOIHNlcnZpY2UgZGVs aXZlcnkmcXVvdDsgWzJdIGRlbGl2ZXJhYmxlLiA8YnI+PGJyPkZyb20geW91ciBsaWFpc29uIHN0 YXRlbWVudCwgd2UgcmVhZCAmcXVvdDtJbiBNRUYgdGVybXMsIGEgJnF1b3Q7c2VydmljZSZxdW90 OyByZWZlcnMgdG8gdGhlIHNldCBvZiBhdHRyaWJ1dGVzIGFuZCB0aGVpciB2YWx1ZXMgdGhhdCBh cmUgYWdyZWVkIGJldHdlZW4gdGhlIHByb3ZpZGVyIG9mIGEgc2VydmljZSBhbmQgdGhlIGN1c3Rv bWVyIG9mIHRoYXQgc2VydmljZS4mcXVvdDsgWW91IHdpbGwgYmUgZ2xhZCB0byBoZWFyIHRoYXQg d2UgdXNlIHRoZSBzYW1lIGRlZmluaXRpb24gaW4gb3VyIEwzU00gd29yay4gQXMgc3VjaCwgdGhl IE1FRiBpbml0aWF0aXZlIG9uIElQIHNlcnZpY2UgYXR0cmlidXRlcyBjbGVhcmx5IHJlbGF0ZXMg dG8gTDNTTS48YnI+PGJyPlRoZSBMM1NNIGNoYWlycyBhbmQgd29ya2luZyBncm91cCBoYXZlIGV4 YW1pbmVkIHRoZSBwcm9wb3NlZCBzY29wZSBvZiB0aGUgaW5pdGlhbCBwaGFzZSBvZiB0aGUgTUVG IElQIFNlcnZpY2UgQXR0cmlidXRlcyBwcm9qZWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iJz4tRGVmaW5pdGlvbiBvZiBhdHRyaWJ1dGVzIGZvciBJUC1jYXBhYmxlIFVO SXMgYW5kIE5OSXMsIGZvciBJUCBTZXJ2aWNlIGNvbm5lY3Rpb25zLCBhbmQgZm9yIElQIFNlcnZp Y2UgRW5kIFBvaW50cyBhdCBVTklzIGFuZCBFTk5Jczxicj4tSVAgYWRkcmVzcyBhbGxvY2F0aW9u cyBhbmQgSVAgY29udHJvbCBwcm90b2NvbHMgKGUuZy4gREhDUCkgZXRjIGF0IFVOSXM8YnI+LU9B TSBhY3Jvc3MgdGhlIGV4dGVybmFsIGludGVyZmFjZSAoYnkgcmVmZXJlbmNlIHRvIElFVEYgcHJv dG9jb2xzIGFuZDxicj5tZWNoYW5pc21zKTxicj4tU2VydmljZSBMZXZlbCBTcGVjaWZpY2F0aW9u IChTTFMpIGRlZmluaXRpb25zIGluY2x1ZGluZyBwZXJmb3JtYW5jZSBtb25pdG9yaW5nL2NvbnN0 cmFpbnRzIChieSByZWZlcmVuY2UgdG8gSUVURiBwcm90b2NvbHMgYW5kIG1ldHJpYyBkZWZpbml0 aW9ucyk8YnI+LVJlZHVuZGFudCBsaW5rcyBhdCBhbiBleHRlcm5hbCBpbnRlcmZhY2UgKFN1YnNj cmliZXIvU2VydmljZSBwcm92aWRlciBvciBiZXR3ZWVuIFNlcnZpY2UgUHJvdmlkZXJzKSwgaW5j bHVkaW5nIG9wdGlvbnMgZm9yIGRpZmZlcmVudCByb3V0aW5nIHByb3RvY29scy48YnI+LU11bHRp LUNvUyBzZXJ2aWNlcyAoaS5lLiBRb1MgY2xhc3NpZmljYXRpb24pIGFuZCBjbGFzc2lmaWNhdGlv biBvZjxicj5HcmVlbi9ZZWxsb3cgcGFja2V0cyBpbmNsdWRpbmcgZGlmZnNlcnYsIEJhbmR3aWR0 aCBwcm9maWxlcywgZXRjLjxicj4tSVB2NCwgSVB2NiBhbmQgZHVhbCBzdGFjayBzZXJ2aWNlczxi cj4tSW50ZXItb3BlcmF0b3IgSVAtVlBOIHNlcnZpY2VzIHVzaW5nIG9wdGlvbnMgQSwgQiBvciBD IGZyb20gUkZDNDM2NDxicj4tVW5pY2FzdCBvbmx5IChtdWx0aWNhc3QgaXMgZGVmZXJlZCB0byBh IGZ1dHVyZSBwaGFzZSkuPGJyPi1PdGhlciB0b3BpY3MgbWF5IGJlIGFkZGVkIGFzIHRoZSBwcm9q ZWN0IHByb2dyZXNzZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdtc28tZmFyZWFzdC1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+PGJyPlRoZSBMM1NNIHdvcmsgYWxyZWFkeSBjb3Zl cnMgbW9zdCBvZiB0aGUgaXRlbXMgaW4gdGhpcyBsaXN0LCBpbmNsdWRpbmcgbXVsdGljYXN0LiZu YnNwOyBIb3dldmVyLCB3ZSBzaG91bGQgb2JzZXJ2ZSB0aGF0Ojxicj4xLiZuYnNwOyBMM1NNIGhh cyBpbml0aWFsbHkgZm9jdXNlZCBvbiB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIGN1c3RvbWVy IGFuZCB0aGUgc2VydmljZSBwcm92aWRlciwgbm90IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBzZXJ2 aWNlcyBwcm92aWRlcnMgb3IgYmV0d2VlbiBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbnMuIFRoZSBj dXJyZW50IHNlcnZpY2UgbW9kZWwgc3VwcG9ydHMgdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIFJG QyA0MzY0IG9wdGlvbiBBIChhcyB0aGlzIGlzIGEgc3Vic2V0IG9mIHRoZSBleGlzdGluZyBzaXRl IG1vZGVsKSwgYW5kIHdlJ3JlIGNvbnNpZGVyaW5nIHdoZXRoZXIgdG8gYWRkIG9wdGlvbiBCIGFu ZCBDLjxicj4yLiZuYnNwOyBUaGUgTDNTTSB3b3JrIGRvZXMgbm90IGNvdmVyIGVpdGhlciB0aGUg U2VydmljZSBMZXZlbCBTcGVjaWZpY2F0aW9uIGRlZmluaXRpb25zIG9yIHRoZSBMaWZlY3ljbGUg U2VydmljZSBPcmNoZXN0cmF0aW9uIGFzIGRlc2NyaWJlZCBpbiB0aGUgTUVGIExpZmVjeWNsZSBT ZXJ2aWNlIE9yY2hlc3RyYXRpb24gKExTTykgUmVmZXJlbmNlIEFyY2hpdGVjdHVyZSAmYW1wOyBG cmFtZXdvcmsuIDxicj48YnI+VGhlIEwzU00gd29yayBzdGFydGVkIGFib3V0IGEgeWVhciBhZ28g YW5kIGlzIGluIHRoZSBmaW5hbCBzdGFnZSBvZiBzdGFuZGFyZGl6YXRpb24uIFRoZXJlZm9yZSwg d2Ugd291bGQgZW5jb3VyYWdlIGFueW9uZSB3aG8gaXMgaW50ZXJlc3RlZCB0byByZXZpZXcgYW5k IHByb3ZpZGUgZmVlZGJhY2sgb24gdGhlIGZ1dHVyZSBzdGFuZGFyZCBieSBzZW5kaW5nIGEgbWVz c2FnZSB0byB0aGUgTDNTTSBtYWlsaW5nIGxpc3QgYXMgc29vbiBhcyBwb3NzaWJsZSAoZGV0YWls cyBhdCBbM10pLiBQbGVhc2Uga2VlcCB1cyBpbmZvcm1lZCBvZiBhbnkgZ2FwcyB5b3UgaWRlbnRp ZnkgdGhhdCBhcmUgbmVlZGVkIHRvIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50cyBpbiB5b3VyIHNw ZWNpZmljYXRpb25zLCB3aXRob3V0IHRoZSBuZWVkIGZvciBhIGZvcm1hbCBsaWFpc29uLiA8YnI+ PGJyPkkgaG9wZSB5b3Ugd2lsbCBhZ3JlZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBub3QgZHVw bGljYXRlIHdvcmsgd2l0aGluIHN0YW5kYXJkaXphdGlvbi4gVGhlcmVmb3JlLCBJIGhvcGUgeW91 IHdpbGwgd29yayB0byBwcm9kdWNlIGV4dGVuc2lvbnMgdG8gdGhlIEwzU00gWUFORyBtb2RlbCBm b3IgYWRkaXRpb25hbCBmZWF0dXJlcyBzdWNoIGFzIHRoZSBTZXJ2aWNlIExldmVsIFNwZWNpZmlj YXRpb24sIGFuZCB3aWxsIG5vdCByZXBlYXQgYW55IG9mIHRoZSBmdW5jdGlvbiBhbHJlYWR5IHBy b3ZpZGVkIGJ5IHRoYXQgbW9kZWwuIElmIHlvdSBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIGRv bid0IGhlc2l0YXRlIHRvIGNvbnRhY3QgdXMuIFdlIGFyZSBhbHdheXMgYXZhaWxhYmxlIGZvciBm dXJ0aGVyIGRpc2N1c3Npb25zIG9yIGNvbmZlcmVuY2UgY2FsbHMgcmVnYXJkaW5nIHRoZSBMM1NN IHNwZWNpZmljYXRpb25zIGNvbnRlbnQuPGJyPjxicj5SZWdhcmRzLCBCZW5vaXQgQ2xhaXNlIChP UFMgQXJlYSBEaXJlY3Rvcik8YnI+PGJyPlsxXSA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2xpYWlzb24vMTQ1OC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlh aXNvbi8xNDU4LzwvYT48YnI+WzJdIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1vZGVsLyI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9kZWwv PC9hPiA8YnI+WzNdIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvbDNz bS9jaGFydGVyLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9sM3NtL2NoYXJ0ZXIv PC9hPjxicj48YnIgc3R5bGU9J21zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrJz48IVtp ZiAhc3VwcG9ydExpbmVCcmVha05ld0xpbmVdPjxiciBzdHlsZT0nbXNvLXNwZWNpYWwtY2hhcmFj dGVyOmxpbmUtYnJlYWsnPjwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJs b2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHBy ZT5UaXRsZTogTGlhaXNvbiBmcm9tIE1FRiBvbiBJUCBTZXJ2aWNlIEF0dHJpYnV0ZXM8bzpwPjwv bzpwPjwvcHJlPjxwcmU+U3VibWlzc2lvbiBEYXRlOiAyMDE2LTAyLTI2PG86cD48L286cD48L3By ZT48cHJlPlVSTCBvZiB0aGUgSUVURiBXZWIgcGFnZTogPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9saWFpc29uLzE0NTgvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2xpYWlzb24vMTQ1OC88L2E+PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+PHByZSBzdHlsZT0nbXNvLW91dGxpbmUtbGV2ZWw6MSc+RnJvbTogJnF1b3Q7UmFnaHUg UmFuZ2FuYXRoYW4mcXVvdDsgPGEgaHJlZj0ibWFpbHRvOnJyYWdodUBjaWVuYS5jb20iPiZsdDty cmFnaHVAY2llbmEuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPjxwcmU+VG86IDxhIGhyZWY9 Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbSI+YmNsYWlzZUBjaXNjby5jb208L2E+LCA8YSBocmVm PSJtYWlsdG86am9lbGphQGJvZ3VzLmNvbSI+am9lbGphQGJvZ3VzLmNvbTwvYT4sIDxhIGhyZWY9 Im1haWx0bzppZXRmQHRyYW1tZWxsLmNoIj5pZXRmQHRyYW1tZWxsLmNoPC9hPiZndDssIDxhIGhy ZWY9Im1haWx0bzppZXRmQHdqY2VydmVueS5jb20iPmlldGZAd2pjZXJ2ZW55LmNvbTwvYT4sIDxh IGhyZWY9Im1haWx0bzpsb2FAcGkubnUiPmxvYUBwaS5udTwvYT4sIDxhIGhyZWY9Im1haWx0bzpz d2FsbG93LmlldGZAZ21haWwuY29tIj5zd2FsbG93LmlldGZAZ21haWwuY29tPC9hPiwgPGEgaHJl Zj0ibWFpbHRvOnJjYWxsb25AanVuaXBlci5uZXQiPnJjYWxsb25AanVuaXBlci5uZXQ8L2E+LCA8 YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayI+YWRyaWFuQG9sZGRvZy5jby51azwv YT4sIDxhIGhyZWY9Im1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20iPmJpbGwud3VAaHVhd2VpLmNv bTwvYT48bzpwPjwvbzpwPjwvcHJlPjxwcmU+Q2M6IEFsdmFybyBSZXRhbmEgPGEgaHJlZj0ibWFp bHRvOmFyZXRhbmFAY2lzY28uY29tIj4mbHQ7YXJldGFuYUBjaXNjby5jb20mZ3Q7PC9hPixKb2Vs IEphZWdnbGkgPGEgaHJlZj0ibWFpbHRvOmpvZWxqYUBib2d1cy5jb20iPiZsdDtqb2VsamFAYm9n dXMuY29tJmd0OzwvYT4sRGVib3JhaCBCcnVuZ2FyZCA8YSBocmVmPSJtYWlsdG86ZGIzNTQ2QGF0 dC5jb20iPiZsdDtkYjM1NDZAYXR0LmNvbSZndDs8L2E+LElQIFBlcmZvcm1hbmNlIE1ldHJpY3Mg RGlzY3Vzc2lvbiBMaXN0IDxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj4mbHQ7aXBwbUBp ZXRmLm9yZyZndDs8L2E+LE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIERpc2N1c3Npb24g TGlzdCA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+Jmx0O21wbHNAaWV0Zi5vcmcmZ3Q7 PC9hPixBZHJpYW4gRmFycmVsIDxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj4m bHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDs8L2E+LFFpbiBXdSA8YSBocmVmPSJtYWlsdG86Ymls bC53dUBodWF3ZWkuY29tIj4mbHQ7YmlsbC53dUBodWF3ZWkuY29tJmd0OzwvYT4sQmlsbCBDZXJ2 ZW55IDxhIGhyZWY9Im1haWx0bzppZXRmQHdqY2VydmVueS5jb20iPiZsdDtpZXRmQHdqY2VydmVu eS5jb20mZ3Q7PC9hPixCcmlhbiBUcmFtbWVsbCA8YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFtbWVs bC5jaCI+Jmx0O2lldDxvOnA+PC9vOnA+PC9hPjwvcHJlPjxwcmU+PHNwYW4gY2xhc3M9TXNvSHlw ZXJsaW5rPjxhIGhyZWY9Im1haWx0bzppZXRmQHRyYW1tZWxsLmNoIj5mQHRyYW1tZWxsLmNoJmd0 OzwvYT48L3NwYW4+LFNwZW5jZXIgRGF3a2lucyA8YSBocmVmPSJtYWlsdG86c3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb20iPiZsdDtzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbSZndDs8 L2E+LEdlb3JnZSBTd2FsbG93IDxhIGhyZWY9Im1haWx0bzpzd2FsbG93LmlldGZAZ21haWwuY29t Ij4mbHQ7c3dhbGxvdy5pZXRmQGdtYWlsLmNvbSZndDs8L2E+LEFsaWEgQXRsYXMgPGEgaHJlZj0i bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj4mbHQ7YWthdGxhc0BnbWFpbC5jb20mZ3Q7PC9hPixU aGUgSUVURiBDaGFpciA8YSBocmVmPSJtYWlsdG86Y2hhaXJAaWV0Zi5vcmciPiZsdDtjaGFpckBp ZXRmLm9yZyZndDs8L2E+LE5hbiBDaGVuIDxhIGhyZWY9Im1haWx0bzpuYW5AbWV0cm9ldGhlcm5l dGZvcnVtLm9yZyI+Jmx0O25hbkBtZXRyb2V0aGVybmV0Zm9ydW0ub3JnJmd0OzwvYT4sUm9zcyBD YWxsb24gPGEgaHJlZj0ibWFpbHRvOnJjYWxsb25AanVuaXBlci5uZXQiPiZsdDtyY2FsbG9uQGp1 bmlwZXIubmV0Jmd0OzwvYT4sTG9hIEFuZGVyc3NvbiA8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51 Ij4mbHQ7bG9hQHBpLm51Jmd0OzwvYT4sQmVub2l0IENsYWlzZSA8YSBocmVmPSJtYWlsdG86YmNs YWlzZUBjaXNjby5jb20iPiZsdDtiY2xhaXNlQGNpc2NvLmNvbSZndDs8L2E+LEwzVlBOIFNlcnZp Y2UgTW9kZWw8c3BhbiBzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+wqAgPC9zcGFuPkRpc2N1c3Np b24gTGlzdCA8YSBocmVmPSJtYWlsdG86bDNzbUBpZXRmLm9yZyI+Jmx0O2wzc21AaWV0Zi5vcmcm Z3Q7PC9hPixCaWxsIEJqb3JrbWFuIDxhIGhyZWY9Im1haWx0bzpiaWxsQG1ldHJvZXRoZXJuZXRm b3J1bS5uZXQiPiZsdDtiaWxsQG1ldHJvZXRoZXJuZXRmb3J1bS5uZXQmZ3Q7PC9hPixNYXJ0aW4g U3RpZW1lcmxpbmcgPGEgaHJlZj0ibWFpbHRvOm1scy5pZXRmQGdtYWlsLmNvbSI+Jmx0O21scy5p ZXRmQGdtYWlsLmNvbSZndDs8L2E+LFJhZ2h1IFJhbmdhbmF0aGFuIDxhIGhyZWY9Im1haWx0bzpy cmFnaHVAY2llbmEuY29tIj4mbHQ7cnJhZ2h1QGNpZW5hLmNvbSZndDs8L2E+LDxvOnA+PC9vOnA+ PC9wcmU+PHByZT5SZXNwb25zZSBDb250YWN0czogPGEgaHJlZj0ibWFpbHRvOnJyYWdodUBjaWVu YS5jb20iPnJyYWdodUBjaWVuYS5jb208L2E+PG86cD48L286cD48L3ByZT48cHJlPlRlY2huaWNh bCBDb250YWN0czogPG86cD48L286cD48L3ByZT48cHJlPlB1cnBvc2U6IEZvciBpbmZvcm1hdGlv bjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Qm9keTog V2Ugd291bGQgbGlrZSB0byBpbmZvcm0geW91IHRoYXQgZHVyaW5nIG91ciAxUTIwMTYgbWVldGlu ZywgTUVGIGhhcyBhcHByb3ZlZCBhIG5ldyBwcm9qZWN0IG9uIElQIFNlcnZpY2UgQXR0cmlidXRl cy4gV2UgaGF2ZSBzZXQgb3V0IHNvbWUgYmFja2dyb3VuZCBhbmQgZnVydGhlciBkZXRhaWxzIGJl bG93LjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+TUVG IGlzIHdlbGwga25vd24gZm9yIHRoZSBkZWZpbml0aW9uIG9mIENhcnJpZXIgRXRoZXJuZXQgKENF KSBzZXJ2aWNlcyAoaW4gTUVGIDYuMiwgTUVGIDMzIGFuZCBNRUYgNTEpIGJhc2VkIG9uIHNlcnZp Y2UgYXR0cmlidXRlcyAoZGVmaW5lZCBpbiBNRUYgMTAuMyBhbmQgTUVGIDI2LjEpLiBJbiBNRUYg dGVybXMsIGEgJnF1b3Q7c2VydmljZSZxdW90OyByZWZlcnMgdG8gdGhlIHNldCBvZiBhdHRyaWJ1 dGVzIGFuZCB0aGVpciB2YWx1ZXMgdGhhdCBhcmUgYWdyZWVkIGJldHdlZW4gdGhlIHByb3ZpZGVy IG9mIGEgc2VydmljZWFuZCB0aGUgY3VzdG9tZXIgb2YgdGhhdCBzZXJ2aWNlLiBUaGVzZSBhdHRy aWJ1dGVzIGFyZSBpbmRlcGVuZGVudCBvZiBob3cgdGhlIHNlcnZpY2UgaXMgaW1wbGVtZW50ZWQ7 IGZvciBleGFtcGxlIGEgQ0Ugc2VydmljZSBjb3VsZCBiZTxvOnA+PC9vOnA+PC9wcmU+PHByZT5p bXBsZW1lbnRlZCB1c2luZyBQcm92aWRlciBCYWNrYm9uZSBCcmlkZ2luZyAoODAyLjFRKSBvciB1 c2luZyBWUExTIChSRkMgNDc2MS80NzYyKSB0byBwcm92aWRlIHRoZSBjb25uZWN0aXZpdHkgYWNy b3NzIHRoZSBzZXJ2aWNlIHByb3ZpZGVyJ3MgbmV0d29yay4gTUVGIGRlZmluZXMgYm90aCBlbmQt dG8tZW5kIHNlcnZpY2VzIGFncmVlZCBiZXR3ZWVuIGEgc3Vic2NyaWJlciBhbmQgYSBzZXJ2aWNl IHByb3ZpZGVyLCB3aGVyZSB0aGUgZW5kIHBvaW50cyBhcmUgYWxsIFVzZXItTmV0d29yayBJbnRl cmZhY2VzIChVTklzKSwgYW5kIGludGVyLXByb3ZpZGVyIHNlcnZpY2VzIHN1cHBsaWVkIGJ5IG9u ZSBzZXJ2aWNlIHByb3ZpZGVyIG9yIG9wZXJhdG9yIHRvIGFub3RoZXIsIHdoZXJlIHRoZSBlbmQg cG9pbnRzIG1heSBiZSBVTklzIG9yIEV4dGVybmFsIE5ldHdvcmstTmV0d29yayBJbnRlcmZhY2Vz IChFTk5JcykuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHBy ZT5Ob3RlIHRoYXQgdGhpcyBkaWZmZXJzIGZyb20gaG93IHRoZSB3b3JkICZxdW90O3NlcnZpY2Um cXVvdDsgaXMgc29tZXRpbWVzIHVzZWQgaW4gSUVURiwgZS5nLiB0byBkZXNjcmliZSBhIHBhcnRp Y3VsYXIgdGVjaG5vbG9neSAoYXMgaW4gJnF1b3Q7VmlydHVhbCBQcml2YXRlIExBTiBTZXJ2aWNl JnF1b3Q7KS48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJl PkFsdGhvdWdoIElQIFNlcnZpY2VzIGFyZSB3aWRlbHkgZGVwbG95ZWQsIHRoZXJlIGlzIGN1cnJl bnRseSBubyBzdGFuZGFyZCBkZWZpbml0aW9uIG9mIHRoZSBhdHRyaWJ1dGVzIGFuZCB2YWx1ZXMg dXNlZCB0byBkZXNjcmliZSB0aGVtLiBFYWNoIFNlcnZpY2UgUHJvdmlkZXIgaGFzIHRoZWlyIG93 biB3YXkgb2YgZGVzY3JpYmluZyBJUCBzZXJ2aWNlcyAoaW5jbHVkaW5nIGluIHNvbWUgY2FzZXMg dGhlaXIgb3duIHRlcm1pbm9sb2d5KTsgdGhpcyBtYWtlcyBpdCBoYXJkIGZvciBjdXN0b21lcnMg dG8gY29tcGFyZSBzZXJ2aWNlIG9mZmVyaW5ncyBmcm9tIGRpZmZlcmVudCBwcm92aWRlcnMsIGFu ZCBpbiBwYXJ0aWN1bGFyIG1ha2VzIGl0IGhhcmQgZm9yIHByb3ZpZGVycyB0byBpbnRlcmNvbm5l Y3Qgd2l0aCBlYWNoIG90aGVyIOKAkyBlYWNoIFNlcnZpY2UgUHJvdmlkZXIgbXVzdCBmb3JtIGEg c3BlY2lmaWMgYmlsYXRlcmFsIGFncmVlbWVudCB3aXRoIGVhY2ggb3RoZXIgU2VydmljZSBQcm92 aWRlciB0aGV5IHdpc2ggdG8gY29ubmVjdCB3aXRoLjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+RnVydGhlcm1vcmUsIHRoZXJlIGlzIGEgZGVzaXJlIGFt b25nIHNlcnZpY2UgcHJvdmlkZXJzIHRvIGltcHJvdmUgc2VydmljZSBkZWxpdmVyeSB0aW1lcyBi eSBhdXRvbWF0aW5nIHRoZSBzZXJ2aWNlIG9yZGVyaW5nIGFuZCBjb25maWd1cmF0aW9uIHByb2Nl c3MuIFRoaXMgaXMgYSBrZXkgYXNwZWN0IG9mIE1FRiBMaWZlY3ljbGUgU2VydmljZXMgT3JjaGVz dHJhdGlvbiAoTFNPKS4gVGhlIGFpbSBvZiBNRUYgTFNPIGlzIHRvIGRlbGl2ZXIgdGhlIE1FRiBU aGlyZCBOZXR3b3JrIHZpc2lvbiwgdG8gcHJvdmlkZSBBc3N1cmVkLCBBZ2lsZSBhbmQgT3JjaGVz dHJhdGVkIHNlcnZpY2VzLiBNRUYgTFNPIGVuYWJsZXMgYXV0b21hdGlvbiBhbmQgb3JjaGVzdHJh dGlvbiBvZiBzZXJ2aWNlIG9yZGVyaW5nIGFuZCBtYW5hZ2VtZW50IGJldHdlZW4gc2VydmljZSBw cm92aWRlcnMgKCZxdW90O0Vhc3QvV2VzdCBpbnRlcmZhY2VzJnF1b3Q7KSB0aHJvdWdoIHRoZSBj cmVhdGlvbiBvZiBzdGFuZGFyZCBkYXRhIG1vZGVscyBhbmQgQVBJcy4gSG93ZXZlciwgYSBwcmUt cmVxdWlzaXRlIGZvciBkZWZpbmluZyB0aG9zZSBpcyB0byBoYXZlIGEgc3RhbmRhcmQgZGVmaW5p dGlvbiBvZiB0aGUgc2VydmljZSB0aGF0IGlzIHRvIGJlIG1hbmFnZWQuPG86cD48L286cD48L3By ZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5UaGUgbmV3IHByb2plY3QgaXMgaW50 ZW5kZWQgdG8gYWRkcmVzcyB0aGVzZSBpc3N1ZXMgYnkgcHJvdmlkaW5nIGEgc3RhbmRhcmQgZGVm aW5pdGlvbiBvZiBJUCBTZXJ2aWNlcywgaW5jbHVkaW5nIGJvdGggZW5kLXRvLWVuZCBzZXJ2aWNl cyBhbmQgaW50ZXItcHJvdmlkZXIgc2VydmljZXMsIHRocm91Z2ggdGhlIGRlZmluaXRpb24gb2Yg YSBzdGFuZGFyZCBzZXQgb2YgU2VydmljZSBBdHRyaWJ1dGVzIHRoYXQgY2FuIGJlIHVzZWQgaW4g ZWFjaCBjYXNlLiBUaGUgc2NvcGUgaXMgbGltaXRlZCB0byBJUC1WUE4gYW5kIEludGVybmV0IEFj Y2VzcyBzZXJ2aWNlczxzcGFuIHN0eWxlPSdtc28tc3BhY2VydW46eWVzJz7CoCA8L3NwYW4+KElQ IHBlZXJpbmcvdHJhbnNpdCBmb3IgaW50ZXJuZXQgdHJhZmZpYyBpcyBwcmVjbHVkZWQpLiBJdCBp cyBpbnRlbmRlZCB0aGF0IHRoaXMgcHJvamVjdCBpcyB0aGUgZmlyc3Qgc3RlcCBpbiBlbmFibGlu ZyBtdWx0aS1vcGVyYXRvciBzZXJ2aWNlIG9yY2hlc3RyYXRpb24gb2YgSVAgU2VydmljZXMgdXNp bmcgTUVGIExTTywgYW5kIHRoYXQgbGF0ZXIgcHJvamVjdHMgd2lsbCB1c2UgdGhlIFNlcnZpY2Ug QXR0cmlidXRlcyB0byBjcmVhdGUgc3RhbmRhcmQgZGF0YSBtb2RlbHMgYW5kIEFQSXMuIFRoZSBp bnRlbnQgb2YgTFNPIGlzIHRvIHByb3ZpZGUgYSBjb21tb24gZnJhbWV3b3JrIGFjcm9zcyBkaWZm ZXJlbnQgc2VydmljZSB0ZWNobm9sb2dpZXM7IE1FRiBpcyB3b3JraW5nIHdpdGggVE1GIGFuZCBP TkYgdG8gY3JlYXRlIGNvbW1vbiBtb2RlbHMgZm9yIHNlcnZpY2VzLCBhbmQgdGhlIHN0YW5kYXJk IGRhdGEgbW9kZWxzIGFuZCBBUElzIGZvciBJUCBTZXJ2aWNlcyB3aWxsIHRpZSBpbnRvIHRoaXMg ZnJhbWV3b3JrLjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxw cmU+V2UgaGF2ZSBub3RlZCB0aGF0IElFVEYgaXMgd29ya2luZyBvbiBhIFlhbmcgbW9kZWwgZm9y IExheWVyIDMgU2VydmljZXMgaW4gdGhlIEwzU00gd29ya2luZyBncm91cC4gQWx0aG91Z2ggdGhl IHNjb3BlIG9mIHRoYXQgcHJvamVjdCBpbiBJRVRGIGlzIGRpZmZlcmVudCwgaXQgaXMgY2xlYXIg dGhlcmUgaXMgc29tZSBzeW5lcmd5IGJldHdlZW4gdGhlIEwzU00gd29yayBhbmQgdGhpcyBNRUYg cHJvamVjdC4gV2UgYmVsaWV2ZSB0aGF0IGJvdGggcHJvamVjdHMgY2FuIGJlbmVmaXQgZnJvbSBp bnB1dCBmcm9tIGVhY2ggb3RoZXIgYW5kIHdlIGhvcGUgdG8gd29yayBjbG9zZWx5IHdpdGggdGhl IEwzU00gd29ya2luZyBncm91cCB0byBlbnN1cmUgb3VyIHNwZWNpZmljYXRpb25zIGFyZSBhbGln bmVkLjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+VGhl IHNjb3BlIG9mIHRoZSBpbml0aWFsIHBoYXNlIG9mIHRoZSBJUCBTZXJ2aWNlIEF0dHJpYnV0ZXMg cHJvamVjdCBpbmNsdWRlczo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+LURlZmluaXRpb24gb2YgYXR0 cmlidXRlcyBmb3IgSVAtY2FwYWJsZSBVTklzIGFuZCBOTklzLCBmb3IgSVAgU2VydmljZSBjb25u ZWN0aW9ucywgYW5kIGZvciBJUCBTZXJ2aWNlIEVuZCBQb2ludHMgYXQgVU5JcyBhbmQgRU5OSXM8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+LUlQIGFkZHJlc3MgYWxsb2NhdGlvbnMgYW5kIElQIGNvbnRy b2wgcHJvdG9jb2xzIChlLmcuIERIQ1ApIGV0YyBhdCBVTklzPG86cD48L286cD48L3ByZT48cHJl Pi1PQU0gYWNyb3NzIHRoZSBleHRlcm5hbCBpbnRlcmZhY2UgKGJ5IHJlZmVyZW5jZSB0byBJRVRG IHByb3RvY29scyBhbmQgbWVjaGFuaXNtcyk8bzpwPjwvbzpwPjwvcHJlPjxwcmU+LVNlcnZpY2Ug TGV2ZWwgU3BlY2lmaWNhdGlvbiAoU0xTKSBkZWZpbml0aW9ucyBpbmNsdWRpbmcgcGVyZm9ybWFu Y2UgbW9uaXRvcmluZy9jb25zdHJhaW50cyAoYnkgcmVmZXJlbmNlIHRvIElFVEYgcHJvdG9jb2xz IGFuZCBtZXRyaWMgZGVmaW5pdGlvbnMpPG86cD48L286cD48L3ByZT48cHJlPi1SZWR1bmRhbnQg bGlua3MgYXQgYW4gZXh0ZXJuYWwgaW50ZXJmYWNlIChTdWJzY3JpYmVyL1NlcnZpY2UgcHJvdmlk ZXIgb3IgYmV0d2VlbiBTZXJ2aWNlIFByb3ZpZGVycyksIGluY2x1ZGluZyBvcHRpb25zIGZvciBk aWZmZXJlbnQgcm91dGluZyBwcm90b2NvbHMuPG86cD48L286cD48L3ByZT48cHJlPi1NdWx0aS1D b1Mgc2VydmljZXMgKGkuZS4gUW9TIGNsYXNzaWZpY2F0aW9uKSBhbmQgY2xhc3NpZmljYXRpb24g b2YgR3JlZW4vWWVsbG93IHBhY2tldHMgaW5jbHVkaW5nIGRpZmZzZXJ2LCBCYW5kd2lkdGggcHJv ZmlsZXMsIGV0Yy48bzpwPjwvbzpwPjwvcHJlPjxwcmU+LUlQdjQsIElQdjYgYW5kIGR1YWwgc3Rh Y2sgc2VydmljZXM8bzpwPjwvbzpwPjwvcHJlPjxwcmU+LUludGVyLW9wZXJhdG9yIElQLVZQTiBz ZXJ2aWNlcyB1c2luZyBvcHRpb25zIEEsIEIgb3IgQyBmcm9tIFJGQzQzNjQ8bzpwPjwvbzpwPjwv cHJlPjxwcmU+LVVuaWNhc3Qgb25seSAobXVsdGljYXN0IGlzIGRlZmVyZWQgdG8gYSBmdXR1cmUg cGhhc2UpLjxvOnA+PC9vOnA+PC9wcmU+PHByZT4tT3RoZXIgdG9waWNzIG1heSBiZSBhZGRlZCBh cyB0aGUgcHJvamVjdCBwcm9ncmVzc2VzLjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPjxwcmU+SXQgaXMgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCB3ZSBpbnRlbmQg dG8gbWFrZSBleHRlbnNpdmUgcmVmZXJlbmNlIHRvIGV4aXN0aW5nIElFVEYgUkZDcyB3aGVyZSBh cHBsaWNhYmxlOyBpdCBpcyBub3Qgb3VyIGludGVudCB0byBzcGVjaWZ5IG5ldyBwcm90b2NvbHMg b3IgbWVjaGFuaXNtcyB3aGVyZSB0aGVyZSBhcmUgZXhpc3Rpbmcgc29sdXRpb25zLjxvOnA+PC9v OnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Tm90ZTogZnVydGhlciBp bmZvcm1hdGlvbiBhYm91dCBNRUYgTFNPIGNhbiBiZSBmb3VuZCBpbiB0aGUgTFNPIFJlZmVyZW5j ZSBBcmNoaXRlY3R1cmUuIFRoZSBmaW5hbCB2ZXJpc29uIGlzIGV4cGVjdGVkIHRvIGJlIHB1Ymxp c2hlZCBpbiBNYXJjaDsgaW4gdGhlIG1lYW50aW1lLCB0aGUgbGF0ZXN0IGFwcHJvdmVkIGRyYWZ0 IGlzIGF2YWlsYWJsZSBhcyBiZWxvdzo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0iaHR0 cHM6Ly9tZWYubmV0L2xpYWlzb24tbG9naW4iPmh0dHBzOi8vbWVmLm5ldC9saWFpc29uLWxvZ2lu PC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT5Vc2VybmFtZTogbWVmPG86cD48L286cD48L3ByZT48 cHJlPkF0dGFjaG1lbnRzOjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPjxwcmU+PHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPsKgwqDCoCA8L3NwYW4+TGlh aXNvbjxvOnA+PC9vOnA+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+ wqDCoMKgIDwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQvZG9jdW1l bnRzL0xJQUlTT04vbGlhaXNvbi0yMDE2LTAyLTI2LW1lZi1pcHBtLW1wbHMtbDNzbS1vcHMtbGlh aXNvbi1mcm9tLW1lZi1vbi1pcC1zZXJ2aWNlLWF0dHJpYnV0ZXMtYXR0YWNobWVudC0xLnBkZiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09OL2xpYWlzb24tMjAx Ni0wMi0yNi1tZWYtaXBwbS1tcGxzLWwzc20tb3BzLWxpYWlzb24tZnJvbS1tZWYtb24taXAtc2Vy dmljZS1hdHRyaWJ1dGVzLWF0dGFjaG1lbnQtMS5wZGY8L2E+PG86cD48L286cD48L3ByZT48cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT4uPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+PC9ibG9ja3F1b3RlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_679E55ADEABC9443947F5AD6F3ED464A21C0BA0E3AONWVEXCHMB03c_-- From nobody Mon Apr 18 03:43:44 2016 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 C99B312D526 for ; Mon, 18 Apr 2016 03:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 uwkz8lwmz2-p for ; Mon, 18 Apr 2016 03:43:41 -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 66A1412D8C3 for ; Mon, 18 Apr 2016 03:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1402; q=dns/txt; s=iport; t=1460976221; x=1462185821; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=TJIhB6SnNBGsCGw5xh6GICiSP0j+1PioWbWx1LMO5Rc=; b=YCQqjUigkelVzLgWwO38C09K/eu8jZiAb3hx/yMpxc/+Io9k/eljgFz/ n5BKz/ole1UsOsbWEEisOm4sR9t0BP7mSmoSxtGWsI9EhfnoXLBwjTpSB OHd8B+sB/pbtK/Zj8fc+9wYVQcGS5hDFanzhwfcXMEVtygAL+jBYnc3or M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAQCUuRRX/xbLJq1bvywBDYFxhg6BY?= =?us-ascii?q?xQBAQEBAQEBZRwLhEQnFUABNQIFFgsCCwMCAQIBSw0IAQGIJakIkRkBAQEBAQU?= =?us-ascii?q?BAQEBHHyFJYhlgyWCVgEEmA6BLoxggWeHVCOFM48rHgEBQoNqOogugTwBAQE?= X-IronPort-AV: E=Sophos;i="5.24,502,1454976000"; d="scan'208";a="676798697" 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; 18 Apr 2016 10:43:39 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3IAhcxY020549; Mon, 18 Apr 2016 10:43:39 GMT To: "l3sm@ietf.org" From: Benoit Claise Message-ID: <5714BA5A.2030701@cisco.com> Date: Mon, 18 Apr 2016 12:43:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Ian Farrer , 'Mikael Abrahamsson' , kristian.larsson@t-systems.se, "Zoric, Sladjana" , "Martin.Adams@telekom.de" Subject: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 18 Apr 2016 10:43:43 -0000 Dear all, Feedback from Kristian Larsson, forwarded with permission. Regards, Benoit =============================================================== Benoit, in my head this model is used not only as an internal representation but also to allow a customer to manage a L3VPN that we (or someone else) provides. I wonder how we as the provider can limit the amount of features that we support. The model includes RIP, OSPF and BGP as PE-CE protocols. There are multicast portions in there and so forth. If we choose to only provide BGP as routing protocol, how can we signal this to the customer? Should we declare deviations? I suppose we can always return an error when the customer sends this to us, but that's not very elegant to do in a model driven world. Introducing if-feature into the model would perhaps be one way, or that the model be carved up into many smaller models that augments base model, for example: - l3vpn-base - l3vpn-bgp - l3vpn-rip - l3vpn-ospf If we only support BGP then we would implement the l3vpn-base model and l3vpn-bgp (which augments base). Customers can clearly see what we support by looking at the netconf capabilities of our orchestration system. Apologies if I missed something in the model, it's a year ago since I read it and I've only skimmed through the latest revision. Kind regards, Kristian. From nobody Mon Apr 18 19:22:36 2016 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 79A7912E8D1 for ; Mon, 18 Apr 2016 19:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, 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 SnMBS502NCHl for ; Mon, 18 Apr 2016 19:22:32 -0700 (PDT) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id F2C2F12E8CF for ; Mon, 18 Apr 2016 19:22:31 -0700 (PDT) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id A1F9EE0120; Tue, 19 Apr 2016 11:22:30 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Tue, 19 Apr 2016 11:22:30 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 70FB94C0058; Tue, 19 Apr 2016 11:22:30 +0900 (JST) Received: from LTMC2151.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id 658244C0051; Tue, 19 Apr 2016 11:22:30 +0900 (JST) Received: from LTMC2151.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u3J2MTsQ011479; Tue, 19 Apr 2016 11:22:30 +0900 Received: from LTMC2151.kddi.com.mid_36205184 (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u3J2CQ6E031318; Tue, 19 Apr 2016 11:12:26 +0900 X-SA-MID: 36205184 Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Tue, 19 Apr 2016 11:12:25 +0900 From: "Ogaki, Kenichi" To: "'Benoit Claise'" , References: <5714BA5A.2030701@cisco.com> In-Reply-To: <5714BA5A.2030701@cisco.com> Date: Tue, 19 Apr 2016 11:12:25 +0900 Message-ID: <010a01d199e0$ea800ec0$bf802c40$@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: AQJQCPqd5x/Xo3VRTakEDozTpZ+zR56Tq9Ag Content-Language: ja X-TM-AS-MML: disable Archived-At: Cc: kristian.larsson@t-systems.se, Martin.Adams@telekom.de, 'Mikael Abrahamsson' , 'Ian Farrer' , "'Zoric, Sladjana'" Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 02:22:34 -0000 Hi All, >Should we declare deviations? I suppose we can always return an error when the customer sends this to us, but that's not very elegant to do >in a model driven world. Introducing if-feature into the model would perhaps be one way, or that the model be carved up into many smaller >models that augments base model, for example: In my understanding, the deviation suits this. (If-)feature is used for a conditional case, ex.) an equipment in a network supports both BGP and OSPF, but another one in the same network can support only BGP. Conformance for the deviation can be checked in the negotiation phase, before a customer send an actual service activation request. https://tools.ietf.org/html/rfc6020#section-5.6.4 This is out of scope for each data model, but the transport protocol or YANG should consider this (and is already considered). Am I missing something? All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Monday, April 18, 2016 7:44 PM To: l3sm@ietf.org Cc: Ian Farrer; 'Mikael Abrahamsson'; kristian.larsson@t-systems.se; Zoric, Sladjana; Martin.Adams@telekom.de Subject: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model Dear all, Feedback from Kristian Larsson, forwarded with permission. Regards, Benoit =============================================================== Benoit, in my head this model is used not only as an internal representation but also to allow a customer to manage a L3VPN that we (or someone else) provides. I wonder how we as the provider can limit the amount of features that we support. The model includes RIP, OSPF and BGP as PE-CE protocols. There are multicast portions in there and so forth. If we choose to only provide BGP as routing protocol, how can we signal this to the customer? Should we declare deviations? I suppose we can always return an error when the customer sends this to us, but that's not very elegant to do in a model driven world. Introducing if-feature into the model would perhaps be one way, or that the model be carved up into many smaller models that augments base model, for example: - l3vpn-base - l3vpn-bgp - l3vpn-rip - l3vpn-ospf If we only support BGP then we would implement the l3vpn-base model and l3vpn-bgp (which augments base). Customers can clearly see what we support by looking at the netconf capabilities of our orchestration system. Apologies if I missed something in the model, it's a year ago since I read it and I've only skimmed through the latest revision. Kind regards, Kristian. _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Mon Apr 18 20:31:52 2016 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 63BE912E969 for ; Mon, 18 Apr 2016 20:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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.996, 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 zQElVFZRumkW for ; Mon, 18 Apr 2016 20:31:49 -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 8C12712E8FA for ; Mon, 18 Apr 2016 20:31:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMP10000; Tue, 19 Apr 2016 03:31:44 +0000 (GMT) Received: from SZXEML422-HUB.china.huawei.com (10.82.67.152) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 19 Apr 2016 04:31:43 +0100 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.108]) by szxeml422-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.03.0235.001; Tue, 19 Apr 2016 11:31:38 +0800 From: wangzitao To: "Ogaki, Kenichi" , "'Benoit Claise'" , "l3sm@ietf.org" Thread-Topic: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHRmV8yosz6E1osBUKZzwfqOjxX85+QCPmAgACXzNA= Date: Tue, 19 Apr 2016 03:31:37 +0000 Message-ID: References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> In-Reply-To: <010a01d199e0$ea800ec0$bf802c40$@kddi.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.13] 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.0A020202.5715A6A0.00BB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.108, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e8b8d25b579056d8ae3b2d74e36b68c7 Archived-At: Cc: 'Ian Farrer' , 'Mikael Abrahamsson' , "kristian.larsson@t-systems.se" , "Martin.Adams@telekom.de" , "'Zoric, Sladjana'" Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 03:31:51 -0000 SGkgQWxsLA0KDQpJTUhPLCB0aGVyZSBhcmUgYWxyZWFkeSBzb21lIGNvbmRpdGlvbmFsIHN0YXRl bWVudHMgbGlrZToNCg0KICAgICAgICAgICAgICAgIGNvbnRhaW5lciBvc3BmIHsNCiAgICAgICAg ICAgICAgICAgICAgd2hlbiAiLi4vdHlwZSA9ICdvc3BmJyIgew0KICAgICAgICAgICAgICAgICAg ICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAiT25seSBhcHBsaWVz DQogICAgICAgICAgICAgICAgICAgICAgICAgd2hlbiBwcm90b2NvbCBpcyBPU1BGLiI7DQogICAg ICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgLi4uDQogICAgICAgICAgICAg ICAgY29udGFpbmVyIGJncCB7DQogICAgICAgICAgICAgICAgICAgIHdoZW4gIi4uL3R5cGUgPSAn YmdwJyIgew0KICAgICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAg ICAgICAgICAgICAgICAiT25seSBhcHBsaWVzIHdoZW4NCiAgICAgICAgICAgICAgICAgICAgICAg ICBwcm90b2NvbCBpcyBCR1AuIjsNCiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAg ICAgICAgICAuLi4NClRoZSB3aGVuIHN0YXRlbWVudCBjYW4gcmVzdHJhaW4gdGhlIG9zcGYvYmdw IGNvbnRhaW5lci4gSWYgbm90IHNhdGlzZmllZCB0aGUgIndoZW4iIHN0YXRlbWVudCwgdGhlIG9z cGYvYmdwIGNvbnRhaW5lciBpcyBpbnZhbGlkLg0KIlRoZSBub2RlIGRlZmluZWQgYnkgdGhlIHBh cmVudCBkYXRhIGRlZmluaXRpb24gc3RhdGVtZW50IGlzIG9ubHkgdmFsaWQgd2hlbiB0aGUgY29u ZGl0aW9uIHNwZWNpZmllZCBieSB0aGUgIndoZW4iDQpzdGF0ZW1lbnQgaXMgc2F0aXNmaWVkLiJb cmZjNjAyMCNzZWN0aW9uLTcuMTkuNS5dDQoNCg0KQmVzdCBSZWdhcmRzIQ0KLU1pY2hhZWwoVEFP KQ0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBPZ2FraSwgS2VuaWNoaQ0Kt6LLzcqxvOQ6IDIwMTbE6jTUwjE5yNUg MTA6MTINCsrVvP7IyzogJ0Jlbm9pdCBDbGFpc2UnOyBsM3NtQGlldGYub3JnDQqzrcvNOiBrcmlz dGlhbi5sYXJzc29uQHQtc3lzdGVtcy5zZTsgTWFydGluLkFkYW1zQHRlbGVrb20uZGU7ICdNaWth ZWwgQWJyYWhhbXNzb24nOyAnSWFuIEZhcnJlcic7ICdab3JpYywgU2xhZGphbmEnDQrW98ziOiBS ZTogW0wzc21dIEZlZWRiYWNrIG9uIGRyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1vZGVs DQoNCkhpIEFsbCwNCg0KPlNob3VsZCB3ZSBkZWNsYXJlIGRldmlhdGlvbnM/IEkgc3VwcG9zZSB3 ZSBjYW4gYWx3YXlzIHJldHVybiBhbiBlcnJvciANCj53aGVuIHRoZSBjdXN0b21lciBzZW5kcyB0 aGlzIHRvIHVzLCBidXQgdGhhdCdzIG5vdCB2ZXJ5IGVsZWdhbnQgdG8gZG8gDQo+aW4gYSBtb2Rl bCBkcml2ZW4gd29ybGQuIEludHJvZHVjaW5nIGlmLWZlYXR1cmUgaW50byB0aGUgbW9kZWwgd291 bGQgcGVyaGFwcyBiZSBvbmUgd2F5LCBvciB0aGF0IHRoZSBtb2RlbCBiZSBjYXJ2ZWQgdXAgaW50 byBtYW55IHNtYWxsZXIgbW9kZWxzIHRoYXQgYXVnbWVudHMgYmFzZSBtb2RlbCwgZm9yIGV4YW1w bGU6DQoNCkluIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBkZXZpYXRpb24gc3VpdHMgdGhpcy4NCihJ Zi0pZmVhdHVyZSBpcyB1c2VkIGZvciBhIGNvbmRpdGlvbmFsIGNhc2UsIGV4LikgYW4gZXF1aXBt ZW50IGluIGEgbmV0d29yayBzdXBwb3J0cyBib3RoIEJHUCBhbmQgT1NQRiwgYnV0IGFub3RoZXIg b25lIGluIHRoZSBzYW1lIG5ldHdvcmsgY2FuIHN1cHBvcnQgb25seSBCR1AuDQoNCkNvbmZvcm1h bmNlIGZvciB0aGUgZGV2aWF0aW9uIGNhbiBiZSBjaGVja2VkIGluIHRoZSBuZWdvdGlhdGlvbiBw aGFzZSwgYmVmb3JlIGEgY3VzdG9tZXIgc2VuZCBhbiBhY3R1YWwgc2VydmljZSBhY3RpdmF0aW9u IHJlcXVlc3QuDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjAyMCNzZWN0aW9uLTUu Ni40DQpUaGlzIGlzIG91dCBvZiBzY29wZSBmb3IgZWFjaCBkYXRhIG1vZGVsLCBidXQgdGhlIHRy YW5zcG9ydCBwcm90b2NvbCBvciBZQU5HIHNob3VsZCBjb25zaWRlciB0aGlzIChhbmQgaXMgYWxy ZWFkeSBjb25zaWRlcmVkKS4NCg0KQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KQWxsIHRoZSBi ZXN0LA0KS2VuaWNoaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTDNzbSBb bWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbm9pdCBDbGFpc2UN ClNlbnQ6IE1vbmRheSwgQXByaWwgMTgsIDIwMTYgNzo0NCBQTQ0KVG86IGwzc21AaWV0Zi5vcmcN CkNjOiBJYW4gRmFycmVyOyAnTWlrYWVsIEFicmFoYW1zc29uJzsga3Jpc3RpYW4ubGFyc3NvbkB0 LXN5c3RlbXMuc2U7IFpvcmljLCBTbGFkamFuYTsgTWFydGluLkFkYW1zQHRlbGVrb20uZGUNClN1 YmplY3Q6IFtMM3NtXSBGZWVkYmFjayBvbiBkcmFmdC1pZXRmLWwzc20tbDN2cG4tc2VydmljZS1t b2RlbA0KDQpEZWFyIGFsbCwNCg0KRmVlZGJhY2sgZnJvbSBLcmlzdGlhbiBMYXJzc29uLCBmb3J3 YXJkZWQgd2l0aCBwZXJtaXNzaW9uLg0KDQpSZWdhcmRzLCBCZW5vaXQNCg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkJl bm9pdCwNCg0KaW4gbXkgaGVhZCB0aGlzIG1vZGVsIGlzIHVzZWQgbm90IG9ubHkgYXMgYW4gaW50 ZXJuYWwgcmVwcmVzZW50YXRpb24gYnV0IGFsc28gdG8gYWxsb3cgYSBjdXN0b21lciB0byBtYW5h Z2UgYSBMM1ZQTiB0aGF0IHdlIChvciBzb21lb25lIGVsc2UpIHByb3ZpZGVzLiBJIHdvbmRlciBo b3cgd2UgYXMgdGhlIHByb3ZpZGVyIGNhbiBsaW1pdCB0aGUgYW1vdW50IG9mIGZlYXR1cmVzIHRo YXQgd2Ugc3VwcG9ydC4gVGhlIG1vZGVsIGluY2x1ZGVzIFJJUCwgT1NQRiBhbmQgQkdQIGFzIFBF LUNFIHByb3RvY29scy4gVGhlcmUgYXJlIG11bHRpY2FzdCBwb3J0aW9ucyBpbiB0aGVyZSBhbmQg c28gZm9ydGguIElmIHdlIGNob29zZSB0byBvbmx5IHByb3ZpZGUgQkdQIGFzIHJvdXRpbmcgcHJv dG9jb2wsIGhvdyBjYW4gd2Ugc2lnbmFsIHRoaXMgdG8gdGhlIGN1c3RvbWVyPyBTaG91bGQgd2Ug ZGVjbGFyZSBkZXZpYXRpb25zPyBJIHN1cHBvc2Ugd2UgY2FuIGFsd2F5cyByZXR1cm4gYW4gZXJy b3Igd2hlbiB0aGUgY3VzdG9tZXIgc2VuZHMgdGhpcyB0byB1cywgYnV0IHRoYXQncyBub3QgdmVy eSBlbGVnYW50IHRvIGRvIGluIGEgbW9kZWwgZHJpdmVuIHdvcmxkLiBJbnRyb2R1Y2luZyBpZi1m ZWF0dXJlIGludG8gdGhlIG1vZGVsIHdvdWxkIHBlcmhhcHMgYmUgb25lIHdheSwgb3IgdGhhdCB0 aGUgbW9kZWwgYmUgY2FydmVkIHVwIGludG8gbWFueSBzbWFsbGVyIG1vZGVscyB0aGF0IGF1Z21l bnRzIGJhc2UgbW9kZWwsIGZvciBleGFtcGxlOg0KICAgIC0gbDN2cG4tYmFzZQ0KICAgIC0gbDN2 cG4tYmdwDQogICAgLSBsM3Zwbi1yaXANCiAgICAtIGwzdnBuLW9zcGYNCg0KSWYgd2Ugb25seSBz dXBwb3J0IEJHUCB0aGVuIHdlIHdvdWxkIGltcGxlbWVudCB0aGUgbDN2cG4tYmFzZSBtb2RlbCBh bmQgbDN2cG4tYmdwICh3aGljaCBhdWdtZW50cyBiYXNlKS4gQ3VzdG9tZXJzIGNhbiBjbGVhcmx5 IHNlZSB3aGF0IHdlIHN1cHBvcnQgYnkgbG9va2luZyBhdCB0aGUgbmV0Y29uZiBjYXBhYmlsaXRp ZXMgb2Ygb3VyIG9yY2hlc3RyYXRpb24gc3lzdGVtLg0KDQpBcG9sb2dpZXMgaWYgSSBtaXNzZWQg c29tZXRoaW5nIGluIHRoZSBtb2RlbCwgaXQncyBhIHllYXIgYWdvIHNpbmNlIEkgcmVhZCBpdCBh bmQgSSd2ZSBvbmx5IHNraW1tZWQgdGhyb3VnaCB0aGUgbGF0ZXN0IHJldmlzaW9uLg0KDQpLaW5k IHJlZ2FyZHMsDQogICAgICBLcmlzdGlhbi4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkwzc20gbWFpbGluZyBsaXN0DQpMM3NtQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkwzc20gbWFpbGluZyBsaXN0DQpM M3NtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20N Cg== From nobody Mon Apr 18 20:34:09 2016 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 EE0EE12DEAE for ; Mon, 18 Apr 2016 20:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.206 X-Spam-Level: X-Spam-Status: No, score=-5.206 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.996, 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 paBXmS3rhrdv for ; Mon, 18 Apr 2016 20:34:05 -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 8CB0912D9BF for ; Mon, 18 Apr 2016 20:34:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMP10180; Tue, 19 Apr 2016 03:34:01 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 19 Apr 2016 04:34:00 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 19 Apr 2016 11:33:54 +0800 From: Qin Wu To: "l3sm@ietf.org" , Xufeng Liu , "stephane.litkowski@orange.com" Thread-Topic: [Yang-multicast] Fwd: Yang-multicast post from stephane.litkowski@orange.com requires approval Thread-Index: AQHRmUx1YJ63CIhhYUCGIILKpL6T6p+QpaMw Date: Tue, 19 Apr 2016 03:33:53 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.66] Content-Type: multipart/related; boundary="_004_B8F9A780D330094D99AF023C5877DABA85318A1Dnkgeml513mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5715A72A.0054, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cfbede6a5432932a6d5aaf2b8f0e6497 Archived-At: Subject: Re: [L3sm] [Yang-multicast] Fwd: Yang-multicast post from stephane.litkowski@orange.com requires approval X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 03:34:07 -0000 --_004_B8F9A780D330094D99AF023C5877DABA85318A1Dnkgeml513mbxchi_ Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA85318A1Dnkgeml513mbxchi_" --_000_B8F9A780D330094D99AF023C5877DABA85318A1Dnkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IEZZSS4NCuWPkeS7tuS6ujogc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0 ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiBbbWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBv cmFuZ2UuY29tXQ0K5Y+R6YCBIOaXtumXtDogMjAxNuW5tDTmnIg15pelIDE3OjUzDQrmlLbku7bk uro6IFh1ZmVuZyBMaXUNCuaKhOmAgTogUWluIFd1DQrkuLvpopg6IFJFOiBbWWFuZy1tdWx0aWNh c3RdIEZ3ZDogWWFuZy1tdWx0aWNhc3QgcG9zdCBmcm9tIHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFu Z2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gcmVxdWlyZXMgYXBw cm92YWwNCg0KSGkgWHVmZW5nLA0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4NCg0KUGxzIGZp bmQgc29tZSBpbmxpbmUgY29tbWVudHMuDQoNCkJlc3QgUmVnYXJkcywNCg0KU3RlcGhhbmUNCg0K DQpGcm9tOiBYdWZlbmcgTGl1IFttYWlsdG86eGxpdUBrdWF0cm90ZWNoLmNvbV0NClNlbnQ6IFR1 ZXNkYXksIE1hcmNoIDI5LCAyMDE2IDE1OjM2DQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIE9CUy9P SU5JUw0KQ2M6IFFpbiBXdQ0KU3ViamVjdDogRlc6IFtZYW5nLW11bHRpY2FzdF0gRndkOiBZYW5n LW11bHRpY2FzdCBwb3N0IGZyb20gc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRv OnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiByZXF1aXJlcyBhcHByb3ZhbA0KDQpIaSBT dGVwaGFuZSwNCg0KU29ycnkgdGhhdCBJIGRpZCBub3QgcmVhbGl6ZSB0aGF0IHlvdSBhcmUgbm90 IG9uIHRoZSBsaXN0LCBzbyBJ4oCZbSBzZW5kaW5nIGl0IHRvIHlvdSBkaXJlY3RseS4NCg0KVGhh bmtzLA0KDQotIFh1ZmVuZw0KDQpGcm9tOiBYdWZlbmcgTGl1IFttYWlsdG86eHVmZW5nLmxpdS5p ZXRmQGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgTWFyY2ggMjUsIDIwMTYgMTA6MjcgUE0NClRv OiAnU3RpZyBWZW5hYXMnIDxzdGlnQHZlbmFhcy5jb208bWFpbHRvOnN0aWdAdmVuYWFzLmNvbT4+ OyB5YW5nLW11bHRpY2FzdEBpZXRmLm9yZzxtYWlsdG86eWFuZy1tdWx0aWNhc3RAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSRTogW1lhbmctbXVsdGljYXN0XSBGd2Q6IFlhbmctbXVsdGljYXN0IHBvc3Qg ZnJvbSBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb20+IHJlcXVpcmVzIGFwcHJvdmFsDQoNCkhpIFN0ZXBoYW5lLA0KDQpPdmVy YWxsIGdvb2QuIEkgaGF2ZSBhIGZldyBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzOg0KDQotIFdoeSB1 bmlvbiBpcyB1c2VkIGZvciBycC1hZGRyZXNzLCBldGMuPyBUaGUgdW5pb24gaXMgYWxyZWFkeSBk ZWZpbmVkDQogIGFzIGluZXQ6aXAtYWRkcmVzcy4NCltTTEldIFRoaXMgd2FzIHRvIGV4cHJlc3Mg dGhhdCBpdCBjb3VsZCBiZSBhbiBpcHY2IG9yIGlwdjQgUlAgYWRkcmVzcy4NCkRvIHlvdSB3YW50 IHRvIHByb3Bvc2Ugc29tZXRoaW5nIGVsc2UgPw0KDQoNCi0gbGVhZiBncm91cCBpcyBhIHR5cGUg b2Yge2lwdjQtYWRkcmVzcyB8IGlwdjYtYWRkcmVzc30sIHdoaWNoIGlzIG5vdA0KICBjb252ZW5p ZW50IHRvIHNwZWNpZnkgbXVsdGlwbGUgZ3JvdXBzIGF0IG9uY2UuIE1hbnkgaW1wbGVtZW50YXRp b25zDQogIHVzZSBhIGdyb3VwIHBvbGljeSB3aGljaCBjYW4gZ2l2ZSBhIGdyb3VwIHJhbmdlLg0K DQpbU0xJXSBDdXJyZW50IHdlIGhhdmUgYSBzaW5nbGUgbGlzdCB3aXRoIFtSUCBncm91cF0gYXMg a2V5cy4NCkkgY2FuIGRlZmluZSB0d28gbmVzdGVkIGxpc3QgdG8gYWRkcmVzcyB5b3VyIHJlcXVp cmVtZW50IDoNCkxpc3QgcnAtdG8tZ3JvdXAtbWFwcGluZyB3aGVyZSB3ZSBkZWZpbmUgUlAgcGFy YW1ldGVycyBsaWtlIHRvZGF5ICwgaXQgd2lsbCB1c2Ugb25seSBycC1hZGRyZXNzIGFzIGtleS4N CkFuZCBpbnN0ZWFkIG9mIGhhdmluZyBhIGdyb3VwIGxlYWYgLCBJIGNhbiBjcmVhdGUgYSBsaXN0 IOKAnGdyb3Vwc+KAnSB1c2luZyBncm91cC1pZCBhcyBrZXkuDQpEb2VzIGl0IHdvcmsgPw0KDQoN Ci0gRG9uJ3Qga25vdyBob3cgZGV0YWlsZWQgdGhlIHNlcnZlciBtb2RlbCB3YW50cyB0byBiZS4g V2hlbg0KICBhbnljYXN0LXJwIGlzIGVuYWJsZWQsIHVzdWFsbHkgd2UgbmVlZCB0byBzcGVjaWZ5 IHRoZQ0KICBhbnljYXN0LWFkZHJlc3MgYW5kIHRoZSBycC1hZGRyZXNzLiBOb3Qgc3VyZSBpZiB3 ZSBuZWVkIHRoZXNlLg0KW1NMSV0gQW55Y2FzdCBSUCBjb25maWcgaXMgb25seSBuZWVkZWQgZm9y IHByb3ZpZGVkIG1hbmFnZWQgUlAsIGluIHRoaXMgY2FzZSAsIHRoZSBSUCBhZGRyZXNzIGNhbiBi ZSBhbGxvY2F0ZWQgYnkgdGhlIHByb3ZpZGVyIGFuZCB0aGVyZSBpcyBubyBuZWVkIHRvIG1lbnRp b24gaXQgaW4gdGhlIG1vZGVsLiBEb2VzIGl0IHdvcmsgPw0KDQoNCi0gRm9yIHRoZSBycC1kaXNj b3Zlcnkgb3B0aW9ucywgdGhlIGRldGFpbHMgYXJlIG5vdCBzcGVjaWZpZWQuIElzIGl0DQogIGlu dGVudGlvbmFsIHRvIGxldCB0aGUgbWFuYWdlbWVudCBzeXN0ZW0gdG8gZmlsbCBpbiB0aGUgZGV0 YWlscz8NCg0KW1NMSV0gV2UgaGF2ZSBpZGVudGl0aWVzIGZvciB0aGF0IDoNCg0KaWRlbnRpdHkg YXV0by1ycCB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJhc2UgbXVsdGljYXN0 LXJwLWRpc2NvdmVyeS10eXBlOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZXNj cmlwdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiQmFzZSBpZGVudGl0eSBm b3IgYXV0by1ycCBkaXNjb3ZlcnkgdHlwZS4iOw0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAg ICAgICAgICBpZGVudGl0eSBzdGF0aWMtcnAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBiYXNlIG11bHRpY2FzdC1ycC1kaXNjb3ZlcnktdHlwZTsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIkJhc2UgaWRlbnRpdHkgZm9yIHN0YXRpYyB0eXBlLiI7DQogICAgICAgICAgICAgICAgfQ0K ICAgICAgICAgICAgICAgIGlkZW50aXR5IGJzci1ycCB7DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGJhc2UgbXVsdGljYXN0LXJwLWRpc2NvdmVyeS10eXBlOw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAiQmFzZSBpZGVudGl0eSBmb3IgQkRSIGRpc2NvdmVyeSB0eXBlLiI7DQogICAgICAg ICAgICAgICAgfQ0KDQotIFRoZSBtb2RlbCBpcyBub3QgYSBkZXZpY2UgbW9kZWwsIGJ1dCBpdCBp bXBvcnRzIGlldGYtcm91dGluZywgd2hpY2gNCiAgaW4gdHVybiBpbXBvcnRzIGlldGYtaW50ZXJm YWNlcy4gU2hvdWxkIHdlIGF2b2lkIHRoZW0/IFRoZSBvbmx5DQogIHVzZWQgaW1wb3J0ZWQgcmVm ZXJlbmNlIGlzIHJ0OmFkZHJlc3MtZmFtaWx5Lg0KDQpbU0xJXSBBZ3JlZSAsIHdlIG9ubHkgdXNl IHRoZSBhZGRyZXNzLWZhbWlseSBhbmQgYWxzbyBwcm90b2NvbCB0eXBlcy4NCklmIHdlIGF2b2lk IGl0LCB3ZSBuZWVkIHRvIHJlZGVmaW5lIGFsbCBvZiB0aGVtIHdoaWNoIGlzIGEgcG9zc2liaWxp dHkuDQpUaG91Z2h0cyA/DQoNCi0gVW5kZXIgYSBzaXRlIGNvbnRhaW5lciBtdWx0aWNhc3QsIHRo ZXJlIGlzIGEgbGVhZiBwcm90b2NvbC10eXBlLA0KICB3aGljaCBzcGVjaWZpZXMgZWl0aGVyIGhv c3Qgb3Igcm91dGVyLiBJbiBjYXNlIG9mIHJvdXRlciwgUElNIHdpbGwNCiAgYmUgZW5hYmxlZC4g RG8gd2UgbmVlZCB0byBoYXZlIHRoZSBQSU0gcGFyYW1ldGVycyBoZXJlPyBJbiBjYXNlIG9mDQog IGhvc3QsIGRvIHdlIG5lZWQgdG8gc3BlY2lmeSB0aGUgZ3JvdXAgaW5mb3JtYXRpb24gaGVyZT8N CltTTEldIEkgZG8gbm90IGtub3csIGRvIHlvdSB0aGluayB0aGVyZSBpcyBhIG5lZWQgZm9yIGN1 c3RvbWVyIHNwZWNpZmljIHBhcmFtZXRlcnMgaGVyZSA/DQoNCg0KLSBEbyB3ZSB3YW50IHRvIHN1 cHBvcnQgTS1MRFAgYmFzZWQgc2lnbmFsaW5nIChSRkM2Mzg4KT8NCltTTEldIFRoaXMgaXMgYSBw cm92aWRlciBkYXRhIElNTywgc28gbm8gbmVlZCB0byBoYXZlIHRoaXMgaW5mb3JtYXRpb24gaW4g dGhlIG1vZGVsLg0KDQpUaGFua3MsDQoNCi0gWHVmZW5nDQoNCkZyb206IFlhbmctbXVsdGljYXN0 IFttYWlsdG86eWFuZy1tdWx0aWNhc3QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0 aWcgVmVuYWFzDQpTZW50OiBGcmlkYXksIE1hcmNoIDE4LCAyMDE2IDY6NTggUE0NClRvOiB5YW5n LW11bHRpY2FzdEBpZXRmLm9yZzxtYWlsdG86eWFuZy1tdWx0aWNhc3RAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbWWFuZy1tdWx0aWNhc3RdIEZ3ZDogWWFuZy1tdWx0aWNhc3QgcG9zdCBmcm9tIHN0ZXBo YW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3Jhbmdl LmNvbT4gcmVxdWlyZXMgYXBwcm92YWwNCg0KSGkNCg0KVGhlcmUgd2FzIGFuIGVtYWlsIHRvIHRo ZSBsaXN0IHRoYXQgSSBmYWlsZWQgdG8gYXBwcm92ZSBpbiB0aW1lLiBTb3JyeS4gUGxlYXNlIHNl ZSB0aGUgZW1haWwgYmVsb3cuDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0t LS0tLQ0KRnJvbTogPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFu ZS5saXRrb3dza2lAb3JhbmdlLmNvbT4+DQpUbzogInlhbmctbXVsdGljYXN0QGlldGYub3JnPG1h aWx0bzp5YW5nLW11bHRpY2FzdEBpZXRmLm9yZz4iIDx5YW5nLW11bHRpY2FzdEBpZXRmLm9yZzxt YWlsdG86eWFuZy1tdWx0aWNhc3RAaWV0Zi5vcmc+Pg0KQ2M6DQpEYXRlOiBUaHUsIDI1IEZlYiAy MDE2IDE2OjMxOjE1ICswMDAwDQpTdWJqZWN0OiBQbGVhc2UgcmV2aWV3IG11bHRpY2FzdCBWUE4g cGFydCBpbiBMM1NNDQpIaSBEVCwNCg0KV2UgYXJlIHdvcmtpbmcgb24gTDNWUE4gc2VydmljZSBt b2RlbCAobm90IGRldmljZSBjb25maWcpLCBhbmQgdGhlcmUgaXMgYSBtdWx0aWNhc3QgcGFydCBp biBpdC4NCkNvdWxkIHlvdSBwbGVhc2UgaGF2ZSBhIGxvb2sgb24gd2hhdCB3ZSBwcm9wb3NlIGZv ciBtdWx0aWNhc3QgVlBOIHRvIGVuc3VyZSB3ZSBhcmUgbm90IG1pc3NpbmcgYSBiaWcgdGhpbmcg PyBUaGVyZSBhcmUgbXVsdGljYXN0IHBhcmFtZXRlcnMgZm9yIFZQTiBhbmQgZm9yIHRoZSBzaXRl cyBpbiBkZWRpY2F0ZWQgY29udGFpbmVycy4NCg0KDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1vZGVsLw0KDQoNCg0KVGhh bmtzLA0KDQoNCltPcmFuZ2UgbG9nb108aHR0cDovL3d3dy5vcmFuZ2UuY29tLz4NCg0KU3RlcGhh bmUgTGl0a293c2tpDQpOZXR3b3JrIEFyY2hpdGVjdA0KT3JhbmdlL1NDRS9FUVVBTlQvT0lOSVMv TkVUDQpPcmFuZ2UgRXhwZXJ0IEZ1dHVyZSBOZXR3b3Jrcw0KcGhvbmU6ICszMyAyIDIzIDI4IDQ5 IDgzIDxodHRwczovL21vbnNpLnNzby5mcmFuY2V0ZWxlY29tLmZyL2luZGV4LmFzcD90YXJnZXQ9 aHR0cCUzQSUyRiUyRmNsaWN2b2ljZS5zc28uZnJhbmNldGVsZWNvbS5mciUyRkNsaWN2b2ljZVYy JTJGVG9vbEJhci5kbyUzRmFjdGlvbiUzRGRlZmF1bHQlMjZyb290c2VydmljZSUzRFNJR05BVFVS RSUyNnRvJTNEKzMzJTIwMiUyMDIzJTIwMjglMjA0OSUyMDgzJTIwPg0KbW9iaWxlOiArMzMgNiAz NyA4NiA5NyA1MiA8aHR0cHM6Ly9tb25zaS5zc28uZnJhbmNldGVsZWNvbS5mci9pbmRleC5hc3A/ dGFyZ2V0PWh0dHAlM0ElMkYlMkZjbGljdm9pY2Uuc3NvLmZyYW5jZXRlbGVjb20uZnIlMkZDbGlj dm9pY2VWMiUyRlRvb2xCYXIuZG8lM0ZhY3Rpb24lM0RkZWZhdWx0JTI2cm9vdHNlcnZpY2UlM0RT SUdOQVRVUkUlMjZ0byUzRCszMyUyMDYlMjAzNyUyMDg2JTIwOTclMjA1MiUyMD4NCnN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNv bT4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsg eW91Lg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsg eW91Lg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA85318A1Dnkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYg OSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt YXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbm lofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0dGVkLCBkaXYuSFRNTFBy ZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLkJhbGxv b25UZXh0LCBsaS5CYWxsb29uVGV4dCwgZGl2LkJhbGxvb25UZXh0DQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMz DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzNA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkZZSS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovk vZMiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+ DQo8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iPnN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtv d3NraUBvcmFuZ2UuY29tIj5tYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+ XQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OuWui+S9kyI+5Y+R6YCBIOaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OuWui+S9kyI+IDIwMTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk65a6L5L2TIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+NDwvc3Bhbj7mnIg8c3BhbiBs YW5nPSJFTi1VUyI+NTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMTc6NTM8YnI+DQo8 L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gWHVmZW5nIExpdTxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBRaW4gV3U8YnI+DQo8L3NwYW4+ PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gUkU6IFtZYW5nLW11bHRpY2FzdF0gRndkOiBZYW5nLW11bHRpY2FzdCBwb3N0IGZyb20NCjxh IGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSI+c3RlcGhhbmUubGl0 a293c2tpQG9yYW5nZS5jb208L2E+IHJlcXVpcmVzIGFwcHJvdmFsPC9zcGFuPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFh1ZmVuZyw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UGxzIGZpbmQgc29tZSBpbmxpbmUgY29tbWVudHMuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5TdGVwaGFuZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gWHVmZW5nIExpdSBbPGEgaHJlZj0ibWFp bHRvOnhsaXVAa3VhdHJvdGVjaC5jb20iPm1haWx0bzp4bGl1QGt1YXRyb3RlY2guY29tPC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAyOSwgMjAxNiAxNTozNjxicj4NCjxi PlRvOjwvYj4gTElUS09XU0tJIFN0ZXBoYW5lIE9CUy9PSU5JUzxicj4NCjxiPkNjOjwvYj4gUWlu IFd1PGJyPg0KPGI+U3ViamVjdDo8L2I+IEZXOiBbWWFuZy1tdWx0aWNhc3RdIEZ3ZDogWWFuZy1t dWx0aWNhc3QgcG9zdCBmcm9tIDxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3Jh bmdlLmNvbSI+DQpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT4gcmVxdWlyZXMgYXBw cm92YWw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgU3RlcGhhbmUsPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNvcnJ5IHRo YXQgSSBkaWQgbm90IHJlYWxpemUgdGhhdCB5b3UgYXJlIG5vdCBvbiB0aGUgbGlzdCwgc28gSeKA mW0gc2VuZGluZyBpdCB0byB5b3UgZGlyZWN0bHkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rcyw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBYdWZlbmc8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gWHVmZW5nIExpdSBbPGEgaHJl Zj0ibWFpbHRvOnh1ZmVuZy5saXUuaWV0ZkBnbWFpbC5jb20iPm1haWx0bzp4dWZlbmcubGl1Lmll dGZAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1hcmNoIDI1LCAy MDE2IDEwOjI3IFBNPGJyPg0KPGI+VG86PC9iPiAnU3RpZyBWZW5hYXMnICZsdDs8YSBocmVmPSJt YWlsdG86c3RpZ0B2ZW5hYXMuY29tIj5zdGlnQHZlbmFhcy5jb208L2E+Jmd0OzsgPGEgaHJlZj0i bWFpbHRvOnlhbmctbXVsdGljYXN0QGlldGYub3JnIj4NCnlhbmctbXVsdGljYXN0QGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW1lhbmctbXVsdGljYXN0XSBGd2Q6IFlhbmct bXVsdGljYXN0IHBvc3QgZnJvbSA8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb20iPg0Kc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+IHJlcXVpcmVzIGFw cHJvdmFsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIFN0ZXBoYW5lLDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PdmVyYWxs IGdvb2QuIEkgaGF2ZSBhIGZldyBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzOjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIFdoeSB1bmlv biBpcyB1c2VkIGZvciBycC1hZGRyZXNzLCBldGMuPyBUaGUgdW5pb24gaXMgYWxyZWFkeSBkZWZp bmVkPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDsgYXMgaW5ldDppcC1hZGRyZXNzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bU0xJXSBUaGlzIHdhcyB0 byBleHByZXNzIHRoYXQgaXQgY291bGQgYmUgYW4gaXB2NiBvciBpcHY0IFJQIGFkZHJlc3MuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkRvIHlvdSB3YW50IHRvIHByb3Bvc2Ugc29tZXRoaW5nIGVsc2UgPzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIGxlYWYgZ3JvdXAgaXMgYSB0eXBlIG9mIHtp cHY0LWFkZHJlc3MgfCBpcHY2LWFkZHJlc3N9LCB3aGljaCBpcyBub3Q8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyBjb252ZW5pZW50 IHRvIHNwZWNpZnkgbXVsdGlwbGUgZ3JvdXBzIGF0IG9uY2UuIE1hbnkgaW1wbGVtZW50YXRpb25z PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDsgdXNlIGEgZ3JvdXAgcG9saWN5IHdoaWNoIGNhbiBnaXZlIGEgZ3JvdXAgcmFuZ2UuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bU0xJXSBDdXJyZW50IHdlIGhhdmUgYSBzaW5n bGUgbGlzdCB3aXRoIFtSUCBncm91cF0gYXMga2V5cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBjYW4gZGVmaW5l IHR3byBuZXN0ZWQgbGlzdCB0byBhZGRyZXNzIHlvdXIgcmVxdWlyZW1lbnQgOjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5MaXN0IHJwLXRvLWdyb3VwLW1hcHBpbmcgd2hlcmUgd2UgZGVmaW5lIFJQIHBhcmFtZXRlcnMg bGlrZSB0b2RheSAsIGl0IHdpbGwgdXNlIG9ubHkgcnAtYWRkcmVzcyBhcyBrZXkuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFuZCBpbnN0ZWFkIG9mIGhhdmluZyBhIGdyb3VwIGxlYWYgLCBJIGNhbiBjcmVhdGUgYSBs aXN0IOKAnGdyb3Vwc+KAnSB1c2luZyBncm91cC1pZCBhcyBrZXkuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRvZXMg aXQgd29yayA/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gRG9uJ3Qga25v dyBob3cgZGV0YWlsZWQgdGhlIHNlcnZlciBtb2RlbCB3YW50cyB0byBiZS4gV2hlbjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7IGFu eWNhc3QtcnAgaXMgZW5hYmxlZCwgdXN1YWxseSB3ZSBuZWVkIHRvIHNwZWNpZnkgdGhlPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsg YW55Y2FzdC1hZGRyZXNzIGFuZCB0aGUgcnAtYWRkcmVzcy4gTm90IHN1cmUgaWYgd2UgbmVlZCB0 aGVzZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+W1NMSV0gQW55Y2FzdCBSUCBjb25maWcgaXMgb25seSBuZWVkZWQg Zm9yIHByb3ZpZGVkIG1hbmFnZWQgUlAsIGluIHRoaXMgY2FzZSAsIHRoZSBSUCBhZGRyZXNzIGNh biBiZSBhbGxvY2F0ZWQgYnkgdGhlIHByb3ZpZGVyIGFuZCB0aGVyZSBpcyBubw0KIG5lZWQgdG8g bWVudGlvbiBpdCBpbiB0aGUgbW9kZWwuIERvZXMgaXQgd29yayA/PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPi0gRm9yIHRoZSBycC1kaXNjb3Zlcnkgb3B0aW9ucywgdGhlIGRl dGFpbHMgYXJlIG5vdCBzcGVjaWZpZWQuIElzIGl0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgaW50ZW50aW9uYWwgdG8gbGV0IHRo ZSBtYW5hZ2VtZW50IHN5c3RlbSB0byBmaWxsIGluIHRoZSBkZXRhaWxzPzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+W1NMSV0gV2UgaGF2ZSBpZGVudGl0aWVzIGZvciB0aGF0IDo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmlkZW50aXR5IGF1dG8tcnAgezwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgYmFzZSBtdWx0aWNhc3QtcnAtZGlzY292ZXJ5LXR5cGU7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJnF1b3Q7QmFzZSBpZGVudGl0eSBmb3IgYXV0by1ycCBkaXNjb3ZlcnkgdHlwZS4mcXVv dDs7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGl0eSBzdGF0aWMt cnAgezwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmFzZSBtdWx0aWNhc3QtcnAtZGlzY292 ZXJ5LXR5cGU7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7QmFzZSBpZGVudGl0eSBmb3Igc3RhdGljIHR5cGUu JnF1b3Q7Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRlbnRpdHkgYnNy LXJwIHs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJhc2UgbXVsdGljYXN0LXJwLWRpc2Nv dmVyeS10eXBlOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0Jhc2UgaWRlbnRpdHkgZm9yIEJEUiBkaXNjb3Zl cnkgdHlwZS4mcXVvdDs7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB9PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBUaGUgbW9kZWwgaXMgbm90IGEgZGV2aWNlIG1vZGVs LCBidXQgaXQgaW1wb3J0cyBpZXRmLXJvdXRpbmcsIHdoaWNoPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgaW4gdHVybiBpbXBvcnRz IGlldGYtaW50ZXJmYWNlcy4gU2hvdWxkIHdlIGF2b2lkIHRoZW0/IFRoZSBvbmx5PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgdXNl ZCBpbXBvcnRlZCByZWZlcmVuY2UgaXMgcnQ6YWRkcmVzcy1mYW1pbHkuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bU0xJXSBBZ3JlZSAsIHdlIG9ubHkgdXNlIHRoZSBhZGRyZXNzLWZh bWlseSBhbmQgYWxzbyBwcm90b2NvbCB0eXBlcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgd2UgYXZvaWQgaXQs IHdlIG5lZWQgdG8gcmVkZWZpbmUgYWxsIG9mIHRoZW0gd2hpY2ggaXMgYSBwb3NzaWJpbGl0eS48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhvdWdodHMgPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gVW5kZXIgYSBzaXRlIGNv bnRhaW5lciBtdWx0aWNhc3QsIHRoZXJlIGlzIGEgbGVhZiBwcm90b2NvbC10eXBlLDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7IHdo aWNoIHNwZWNpZmllcyBlaXRoZXIgaG9zdCBvciByb3V0ZXIuIEluIGNhc2Ugb2Ygcm91dGVyLCBQ SU0gd2lsbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7IGJlIGVuYWJsZWQuIERvIHdlIG5lZWQgdG8gaGF2ZSB0aGUgUElNIHBhcmFt ZXRlcnMgaGVyZT8gSW4gY2FzZSBvZjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7IGhvc3QsIGRvIHdlIG5lZWQgdG8gc3BlY2lmeSB0 aGUgZ3JvdXAgaW5mb3JtYXRpb24gaGVyZT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1NMSV0gSSBkbyBub3Qga25v dywgZG8geW91IHRoaW5rIHRoZXJlIGlzIGEgbmVlZCBmb3IgY3VzdG9tZXIgc3BlY2lmaWMgcGFy YW1ldGVycyBoZXJlID88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBEbyB3 ZSB3YW50IHRvIHN1cHBvcnQgTS1MRFAgYmFzZWQgc2lnbmFsaW5nIChSRkM2Mzg4KT88L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+W1NMSV0gVGhpcyBpcyBhIHByb3ZpZGVyIGRhdGEgSU1PLCBzbyBubyBuZWVkIHRvIGhh dmUgdGhpcyBpbmZvcm1hdGlvbiBpbiB0aGUgbW9kZWwuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtz LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4tIFh1ZmVuZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gWWFuZy1tdWx0aWNhc3QgWzxhIGhyZWY9Im1haWx0bzp5 YW5nLW11bHRpY2FzdC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86eWFuZy1tdWx0aWNhc3QtYm91 bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlN0aWcgVmVuYWFzPGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMTgsIDIwMTYgNjo1OCBQTTxicj4NCjxiPlRvOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOnlhbmctbXVsdGljYXN0QGlldGYub3JnIj55YW5nLW11bHRpY2Fz dEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1lhbmctbXVsdGljYXN0XSBGd2Q6 IFlhbmctbXVsdGljYXN0IHBvc3QgZnJvbSA8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb20iPg0Kc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+IHJlcXVp cmVzIGFwcHJvdmFsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGVyZSB3YXMgYW4gZW1haWwgdG8gdGhlIGxpc3QgdGhhdCBJIGZhaWxlZCB0 byBhcHByb3ZlIGluIHRpbWUuIFNvcnJ5LiBQbGVhc2Ugc2VlIHRoZSBlbWFpbCBiZWxvdy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0t LS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiZuYnNwOyZsdDs8 YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iPnN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tPC9hPiZndDs8YnI+DQpUbzombmJzcDsmcXVvdDs8YSBocmVmPSJt YWlsdG86eWFuZy1tdWx0aWNhc3RAaWV0Zi5vcmciPnlhbmctbXVsdGljYXN0QGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhbmctbXVsdGljYXN0QGlldGYub3JnIj55YW5n LW11bHRpY2FzdEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KQ2M6Jm5ic3A7PGJyPg0KRGF0ZTombmJz cDtUaHUsIDI1IEZlYiAyMDE2IDE2OjMxOjE1ICYjNDM7MDAwMDxicj4NClN1YmplY3Q6Jm5ic3A7 UGxlYXNlIHJldmlldyBtdWx0aWNhc3QgVlBOIHBhcnQgaW4gTDNTTTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+SGkgRFQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+V2UgYXJlIHdvcmtpbmcgb24gTDNW UE4gc2VydmljZSBtb2RlbCAobm90IGRldmljZSBjb25maWcpLCBhbmQgdGhlcmUgaXMgYSBtdWx0 aWNhc3QgcGFydCBpbiBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Db3VsZCB5b3UgcGxlYXNlIGhhdmUgYSBsb29rIG9u IHdoYXQgd2UgcHJvcG9zZSBmb3IgbXVsdGljYXN0IFZQTiB0byBlbnN1cmUgd2UgYXJlIG5vdCBt aXNzaW5nIGEgYmlnIHRoaW5nID8gVGhlcmUgYXJlIG11bHRpY2FzdCBwYXJhbWV0ZXJzIGZvciBW UE4gYW5kIGZvciB0aGUNCiBzaXRlcyBpbiBkZWRpY2F0ZWQgY29udGFpbmVycy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1vZGVsLyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWwzc20t bDN2cG4tc2VydmljZS1tb2RlbC88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3Ms PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cDovL3d3 dy5vcmFuZ2UuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRp b246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSI0MCIgaGVpZ2h0PSI0MCIgaWQ9Il94MDAw MF9pMTAyNSIgc3JjPSJjaWQ6cGFydDE0LjA5MDAwNjA5LjA3MDYwOTAxQGNpc2NvLmNvbSIgYWx0 PSJPcmFuZ2UgbG9nbyI+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdGVwaGFuZSBMaXRrb3dza2kN Cjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TmV0d29yayBBcmNoaXRlY3QNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5PcmFuZ2UvU0NFL0VRVUFOVC9PSU5JUy9ORVQ8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9yYW5nZSBFeHBlcnQgRnV0dXJlIE5l dHdvcmtzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5waG9uZToNCjxhIGhyZWY9Imh0dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20uZnIvaW5k ZXguYXNwP3RhcmdldD1odHRwJTNBJTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxlY29tLmZy JTJGQ2xpY3ZvaWNlVjIlMkZUb29sQmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJvb3RzZXJ2 aWNlJTNEU0lHTkFUVVJFJTI2dG8lM0QmIzQzOzMzJTIwMiUyMDIzJTIwMjglMjA0OSUyMDgzJTIw IiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPiYjNDM7MzMgMiAyMyAyOCA0OSA4MyA8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5tb2JpbGU6DQo8YSBocmVmPSJodHRwczovL21vbnNpLnNzby5mcmFuY2V0ZWxlY29tLmZyL2lu ZGV4LmFzcD90YXJnZXQ9aHR0cCUzQSUyRiUyRmNsaWN2b2ljZS5zc28uZnJhbmNldGVsZWNvbS5m ciUyRkNsaWN2b2ljZVYyJTJGVG9vbEJhci5kbyUzRmFjdGlvbiUzRGRlZmF1bHQlMjZyb290c2Vy dmljZSUzRFNJR05BVFVSRSUyNnRvJTNEJiM0MzszMyUyMDYlMjAzNyUyMDg2JTIwOTclMjA1MiUy MCIgdGFyZ2V0PSJfYmxhbmsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3Jh dGlvbjpub25lIj4mIzQzOzMzIDYgMzcgODYgOTcgNTIgPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4g bGFuZz0iRlIiPjxicj4NCjxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3Jhbmdl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0ZG NjYwMDt0ZXh0LWRlY29yYXRpb246bm9uZSI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208 L3NwYW4+PC9hPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0Ij4NCjxzcGFuIGxh bmc9IkZSIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5DZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+T3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rIHlvdS48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5DZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBk ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+dGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5J ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABA85318A1Dnkgeml513mbxchi_-- --_004_B8F9A780D330094D99AF023C5877DABA85318A1Dnkgeml513mbxchi_ Content-Type: image/jpeg; name="ATT00001.jpg" Content-Description: ATT00001.jpg Content-Disposition: inline; filename="ATT00001.jpg"; size=997; creation-date="Mon, 18 Apr 2016 08:29:43 GMT"; modification-date="Mon, 18 Apr 2016 08:29:43 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDvpvGt nDO8Zt5iUbaTgc0n/CdWf/PvP+lcffjF9cf9dDUHFfNyzKum1f8AA+np5Vh5RTd/vO2/4Tqz/wCf ab8hR/wnVn/z7TfkK4nijip/tSv3/Av+yMP5/edt/wAJ1Z/8+035CiuJ4oo/tSv3/AP7Iw/n95Pf /wDIQuP+uhqv1IrTl0y6u7y4kjVdvnFQWbGT6Cmf2Je7kUqgZxkKW5rmlRqOTsjpp16cYJOSKFFa P9g3+5k8tAVbbgt1OM8U3+xL4oGEa5IB2bvmwTjOKn6vV/lL+tUv5kUKK0bjSHso83sgiLfcCjcD 9fSiplRlF2aCNeE1eLOi/sDVYpZTBcW+xpDIodclSe/1pBoGtCcS/arYuE8vJXqv+NFFfT/VoeZ8 n9an2X3Dn0TW5JA7XNtuD7x8vfGKtPpWo/YgivCLjAXzc9MHIooqlhoK+5LxM3bb7jOvPDGq3+PP uLc4OflBHPrRRRWTwFGbvK/3m8cxrwVlb7j/2Q== --_004_B8F9A780D330094D99AF023C5877DABA85318A1Dnkgeml513mbxchi_-- From nobody Tue Apr 19 00:33:54 2016 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 50A5A12DD78 for ; Tue, 19 Apr 2016 00:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 exn43n90-41u for ; Tue, 19 Apr 2016 00:33:51 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45C212DCB6 for ; Tue, 19 Apr 2016 00:33:50 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 055B1203A5; Tue, 19 Apr 2016 09:33:49 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id A44CA1A0067; Tue, 19 Apr 2016 09:33:48 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0279.002; Tue, 19 Apr 2016 09:33:48 +0200 From: To: "Ogaki, Kenichi" , 'Benoit Claise' , "l3sm@ietf.org" Thread-Topic: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHRmV8v5MUcs4/sNkyHy/KxHn2YC5+QbY6AgAB7CxA= Date: Tue, 19 Apr 2016 07:33:47 +0000 Message-ID: <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> In-Reply-To: <010a01d199e0$ea800ec0$bf802c40$@kddi.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.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: 'Ian Farrer' , 'Mikael Abrahamsson' , "kristian.larsson@t-systems.se" , "Martin.Adams@telekom.de" , "'Zoric, Sladjana'" Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 07:33:53 -0000 Yep, deviation looks the good way to do. As for device config, if a device does not support a config statement, it a= dvertises a deviation. Same thing here ... -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Tuesday, April 19, 2016 04:12 To: 'Benoit Claise'; l3sm@ietf.org Cc: kristian.larsson@t-systems.se; Martin.Adams@telekom.de; 'Mikael Abraham= sson'; 'Ian Farrer'; 'Zoric, Sladjana' Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model Hi All, >Should we declare deviations? I suppose we can always return an error=20 >when the customer sends this to us, but that's not very elegant to do=20 >in a model driven world. Introducing if-feature into the model would perha= ps be one way, or that the model be carved up into many smaller models that= augments base model, for example: In my understanding, the deviation suits this. (If-)feature is used for a conditional case, ex.) an equipment in a network= supports both BGP and OSPF, but another one in the same network can suppor= t only BGP. Conformance for the deviation can be checked in the negotiation phase, befo= re a customer send an actual service activation request. https://tools.ietf.org/html/rfc6020#section-5.6.4 This is out of scope for each data model, but the transport protocol or YAN= G should consider this (and is already considered). Am I missing something? All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Monday, April 18, 2016 7:44 PM To: l3sm@ietf.org Cc: Ian Farrer; 'Mikael Abrahamsson'; kristian.larsson@t-systems.se; Zoric,= Sladjana; Martin.Adams@telekom.de Subject: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model Dear all, Feedback from Kristian Larsson, forwarded with permission. Regards, Benoit =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Benoit, in my head this model is used not only as an internal representation but al= so to allow a customer to manage a L3VPN that we (or someone else) provides= . I wonder how we as the provider can limit the amount of features that we = support. The model includes RIP, OSPF and BGP as PE-CE protocols. There are= multicast portions in there and so forth. If we choose to only provide BGP= as routing protocol, how can we signal this to the customer? Should we dec= lare deviations? I suppose we can always return an error when the customer = sends this to us, but that's not very elegant to do in a model driven world= . Introducing if-feature into the model would perhaps be one way, or that t= he model be carved up into many smaller models that augments base model, fo= r example: - l3vpn-base - l3vpn-bgp - l3vpn-rip - l3vpn-ospf If we only support BGP then we would implement the l3vpn-base model and l3v= pn-bgp (which augments base). Customers can clearly see what we support by = looking at the netconf capabilities of our orchestration system. Apologies if I missed something in the model, it's a year ago since I read = it and I've only skimmed through the latest revision. Kind regards, Kristian. _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm _______________________________________________ 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 Tue Apr 19 00:55:19 2016 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 8778912D8A8 for ; Tue, 19 Apr 2016 00:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 XgTkiig7SAwT for ; Tue, 19 Apr 2016 00:55:15 -0700 (PDT) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E1812D72A for ; Tue, 19 Apr 2016 00:55:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id D24B9261846; Tue, 19 Apr 2016 09:55:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YPQ6+TE33ts; Tue, 19 Apr 2016 09:55:11 +0200 (CEST) Received: from Kristians-MacBook-Pro.local (h-161-130.a515.priv.bahnhof.se [155.4.161.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id F075526180E; Tue, 19 Apr 2016 09:55:10 +0200 (CEST) To: "Ogaki, Kenichi" , 'Benoit Claise' , l3sm@ietf.org References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> From: Kristian Larsson Message-ID: <5715E45E.80304@spritelink.net> Date: Tue, 19 Apr 2016 09:55:10 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <010a01d199e0$ea800ec0$bf802c40$@kddi.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Martin.Adams@telekom.de, 'Mikael Abrahamsson' , 'Ian Farrer' , "'Zoric, Sladjana'" Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 07:55:18 -0000 On 19/04/16 04:12, Ogaki, Kenichi wrote: > Hi All, > >> Should we declare deviations? I suppose we can always return an >> error when the customer sends this to us, but that's not very >> elegant to do in a model driven world. Introducing if-feature into >> the model would perhaps be one way, or that the model be carved up >> into many smaller models that augments base model, for example: > > In my understanding, the deviation suits this. (If-)feature is used > for a conditional case, ex.) an equipment in a network supports both > BGP and OSPF, but another one in the same network can support only > BGP. With that explanation I think if-feature is just as good a fit, if not better, than deviations. > Conformance for the deviation can be checked in the negotiation > phase, before a customer send an actual service activation request. > https://tools.ietf.org/html/rfc6020#section-5.6.4 This is out of > scope for each data model, but the transport protocol or YANG should > consider this (and is already considered). > > Am I missing something? One problem I see with deviations is that I believe there is no clean standardised way of defining them. Let's say there are 10 L3VPN providers out there that all define that BGP is the only PE-CE protocol support and no multicast. How many different deviations will we see? 1? 10? The normal case here isn't to support the full model. I doubt anyone actually will, so I think it's a bit backwards to define the model with all features and then expect people to use deviations. I think it's a lot cleaner for a customer to look at NETCONF capabilities and see l3vpn-base & l3vpn-bgp to understand the provider only supports BGP as PE-CE protocol, compared to parsing deviation files. if-feature would also be easier to look at than deviation. kll > -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] > On Behalf Of Benoit Claise Sent: Monday, April 18, 2016 7:44 PM To: > l3sm@ietf.org Cc: Ian Farrer; 'Mikael Abrahamsson'; > kristian.larsson@t-systems.se; Zoric, Sladjana; > Martin.Adams@telekom.de Subject: [L3sm] Feedback on > draft-ietf-l3sm-l3vpn-service-model > > Dear all, > > Feedback from Kristian Larsson, forwarded with permission. > > Regards, Benoit > > =============================================================== > > Benoit, > > in my head this model is used not only as an internal representation > but also to allow a customer to manage a L3VPN that we (or someone > else) provides. I wonder how we as the provider can limit the amount > of features that we support. The model includes RIP, OSPF and BGP as > PE-CE protocols. There are multicast portions in there and so forth. > If we choose to only provide BGP as routing protocol, how can we > signal this to the customer? Should we declare deviations? I suppose > we can always return an error when the customer sends this to us, but > that's not very elegant to do in a model driven world. Introducing > if-feature into the model would perhaps be one way, or that the model > be carved up into many smaller models that augments base model, for > example: - l3vpn-base - l3vpn-bgp - l3vpn-rip - l3vpn-ospf > > If we only support BGP then we would implement the l3vpn-base model > and l3vpn-bgp (which augments base). Customers can clearly see what > we support by looking at the netconf capabilities of our > orchestration system. > > Apologies if I missed something in the model, it's a year ago since I > read it and I've only skimmed through the latest revision. > > Kind regards, Kristian. > > _______________________________________________ L3sm mailing list > L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm > From nobody Tue Apr 19 00:57:50 2016 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 ED7E612E268 for ; Tue, 19 Apr 2016 00:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 oovvtsN45ivU for ; Tue, 19 Apr 2016 00:57:44 -0700 (PDT) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6209512E2BD for ; Tue, 19 Apr 2016 00:57:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 24705261846; Tue, 19 Apr 2016 09:57:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xaKS+2qDxiy; Tue, 19 Apr 2016 09:57:41 +0200 (CEST) Received: from Kristians-MacBook-Pro.local (h-161-130.a515.priv.bahnhof.se [155.4.161.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 051A126180E; Tue, 19 Apr 2016 09:57:40 +0200 (CEST) To: stephane.litkowski@orange.com, "Ogaki, Kenichi" , 'Benoit Claise' , "l3sm@ietf.org" References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Kristian Larsson Message-ID: <5715E4F4.6090303@spritelink.net> Date: Tue, 19 Apr 2016 09:57:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "'Zoric, Sladjana'" , 'Mikael Abrahamsson' , 'Ian Farrer' , "Martin.Adams@telekom.de" Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 07:57:49 -0000 On 19/04/16 09:33, stephane.litkowski@orange.com wrote: > Yep, deviation looks the good way to do. As for device config, if a > device does not support a config statement, it advertises a > deviation. Same thing here ... Or the model is built with if-features so the device can cleanly announce what it supports. kll From nobody Tue Apr 19 01:53:23 2016 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 86D9812D136 for ; Tue, 19 Apr 2016 01:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 jUOsy8oCiVXa for ; Tue, 19 Apr 2016 01:53:20 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 14FEE12DD2D for ; Tue, 19 Apr 2016 01:53:20 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id C63141AE0383; Tue, 19 Apr 2016 10:53:18 +0200 (CEST) Date: Tue, 19 Apr 2016 10:53:31 +0200 (CEST) Message-Id: <20160419.105331.1826284903162838136.mbj@tail-f.com> To: kristian@spritelink.net From: Martin Bjorklund In-Reply-To: <5715E4F4.6090303@spritelink.net> References: <010a01d199e0$ea800ec0$bf802c40$@kddi.com> <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5715E4F4.6090303@spritelink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: l3sm@ietf.org, stephane.litkowski@orange.com, ke-oogaki@kddi.com, ian.farrer@telekom.de, mikael.abrahamsson@t-systems.com, Sladjana.Zoric@telekom.de, bclaise@cisco.com, Martin.Adams@telekom.de Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 08:53:21 -0000 Kristian Larsson wrote: > > > On 19/04/16 09:33, stephane.litkowski@orange.com wrote: > > Yep, deviation looks the good way to do. As for device config, if a > > device does not support a config statement, it advertises a > > deviation. Same thing here ... > > Or the model is built with if-features so the device can cleanly > announce what it supports. >From a pure YANG perspective, if-features are better in this case than deviations. Features should be used when you define "conformance profiles" at model design time. Deviations are used *by specific implementations* when they fail to implement a specific conformance profile. /martin From nobody Tue Apr 19 03:13:34 2016 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 C8DCC12E0D4 for ; Tue, 19 Apr 2016 03:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 bM0hqdSdQXd8 for ; Tue, 19 Apr 2016 03:13:31 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A0512E0CE for ; Tue, 19 Apr 2016 03:13:30 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 7E965203E3; Tue, 19 Apr 2016 12:13:29 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 2B5A820067; Tue, 19 Apr 2016 12:13:29 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0279.002; Tue, 19 Apr 2016 12:13:28 +0200 From: To: Kristian Larsson , "Ogaki, Kenichi" , 'Benoit Claise' , "l3sm@ietf.org" Thread-Topic: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHRmV8v5MUcs4/sNkyHy/KxHn2YC5+QbY6AgAB7CxD//+VsAIAARvLw Date: Tue, 19 Apr 2016 10:13:28 +0000 Message-ID: <15600_1461060809_571604C9_15600_294_1_9E32478DFA9976438E7A22F69B08FF921BB059BF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5715E4F4.6090303@spritelink.net> In-Reply-To: <5715E4F4.6090303@spritelink.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "'Zoric, Sladjana'" , 'Mikael Abrahamsson' , 'Ian Farrer' , "Martin.Adams@telekom.de" Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 10:13:33 -0000 The main issue with features is to define what should be a feature , and wh= at is in the base and I'm afraid that we could fall in infinite discussions. -----Original Message----- From: Kristian Larsson [mailto:kristian@spritelink.net]=20 Sent: Tuesday, April 19, 2016 09:58 To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; l3sm@iet= f.org Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sl= adjana' Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model On 19/04/16 09:33, stephane.litkowski@orange.com wrote: > Yep, deviation looks the good way to do. As for device config, if a=20 > device does not support a config statement, it advertises a deviation.=20 > Same thing here ... Or the model is built with if-features so the device can cleanly announce w= hat it supports. kll ___________________________________________________________________________= ______________________________________________ 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 prvs=910e800a0=kristian.larsson@t-systems.se Mon Apr 18 23:54:03 2016 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 E0FA412D761 for ; Mon, 18 Apr 2016 23:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 HhPQu_fo2M1s for ; Mon, 18 Apr 2016 23:54:01 -0700 (PDT) Received: from mail02.credocom.dk (mail02.credocom.dk [94.18.244.42]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306FB12D0C6 for ; Mon, 18 Apr 2016 23:54:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,505,1454972400"; d="scan'208";a="1053315" Received: from TSY-S-EXC01.ts.local (10.41.121.94) by TSY-S-EXC01.ts.local (10.41.121.94) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 19 Apr 2016 08:53:55 +0200 Received: from TSY-S-EXC01.ts.local ([fe80::d03c:cb17:9ca5:e877]) by TSY-S-EXC01.ts.local ([fe80::d03c:cb17:9ca5:e877%12]) with mapi id 15.00.1156.000; Tue, 19 Apr 2016 08:53:55 +0200 From: Kristian Larsson To: wangzitao , "Ogaki, Kenichi" , 'Benoit Claise' , "l3sm@ietf.org" Thread-Topic: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHRmV8pA62rb3lZlEKscMYsathslp+QbY6AgAAWIYCAADiIgA== Date: Tue, 19 Apr 2016 06:53:54 +0000 Message-ID: <5715D605.8050402@t-systems.se> References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> In-Reply-To: Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [155.4.161.130] Content-Type: text/plain; charset="gb2312" Content-ID: <482419D015D5144893FBCC4F06A32C56@ts.local> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 19 Apr 2016 04:43:42 -0700 Cc: "'Zoric, Sladjana'" , Mikael Abrahamsson , 'Ian Farrer' , "Martin.Adams@telekom.de" Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 07:00:18 -0000 DQoNCk9uIDE5LzA0LzE2IDA1OjMxLCB3YW5neml0YW8gd3JvdGU6DQo+IEhpIEFsbCwNCj4NCj4g SU1ITywgdGhlcmUgYXJlIGFscmVhZHkgc29tZSBjb25kaXRpb25hbCBzdGF0ZW1lbnRzIGxpa2U6 DQo+DQo+ICAgICAgICAgICAgICAgICAgY29udGFpbmVyIG9zcGYgew0KPiAgICAgICAgICAgICAg ICAgICAgICB3aGVuICIuLi90eXBlID0gJ29zcGYnIiB7DQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICJPbmx5IGFwcGxp ZXMNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB3aGVuIHByb3RvY29sIGlzIE9TUEYuIjsN Cj4gICAgICAgICAgICAgICAgICAgICAgfQ0KPiAgICAgICAgICAgICAgICAgICAgICAuLi4NCj4g ICAgICAgICAgICAgICAgICBjb250YWluZXIgYmdwIHsNCj4gICAgICAgICAgICAgICAgICAgICAg d2hlbiAiLi4vdHlwZSA9ICdiZ3AnIiB7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBkZXNj cmlwdGlvbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICJPbmx5IGFwcGxpZXMgd2hlbg0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb3RvY29sIGlzIEJHUC4iOw0KPiAgICAgICAg ICAgICAgICAgICAgICB9DQo+ICAgICAgICAgICAgICAgICAgICAgIC4uLg0KPiBUaGUgd2hlbiBz dGF0ZW1lbnQgY2FuIHJlc3RyYWluIHRoZSBvc3BmL2JncCBjb250YWluZXIuIElmIG5vdA0Kc2F0 aXNmaWVkIHRoZSAid2hlbiIgc3RhdGVtZW50LCB0aGUgb3NwZi9iZ3AgY29udGFpbmVyIGlzIGlu dmFsaWQuDQo+ICJUaGUgbm9kZSBkZWZpbmVkIGJ5IHRoZSBwYXJlbnQgZGF0YSBkZWZpbml0aW9u IHN0YXRlbWVudCBpcyBvbmx5DQp2YWxpZCB3aGVuIHRoZSBjb25kaXRpb24gc3BlY2lmaWVkIGJ5 IHRoZSAid2hlbiINCj4gc3RhdGVtZW50IGlzIHNhdGlzZmllZC4iW3JmYzYwMjAjc2VjdGlvbi03 LjE5LjUuXQ0KDQoiLi4vdHlwZSIgaXMgZmlsbGVkIG91dCBieSB0aGUgY3VzdG9tZXIgYW5kIG5v dCBieSB0aGUgcHJvdmlkZXIgKG1lKSBzbyANCkkgZG9uJ3QgdGhpcyBpcyBhcHBsaWNhYmxlLiBJ dCdzIG9ubHkgdG8ga2VlcCBjb25zaXN0ZW5jeSB3aXRoaW4gdGhlIA0KbW9kZWwgLSBkb2Vzbid0 IGxpbWl0IGluc3RhbmNlIGRhdGEgaW5wdXQgZm9yIHRoZSAuLi90eXBlDQoNCiAgICBrbGwNCg0K DQoNCg0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IEwzc20gW21haWx0bzpsM3Nt LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gT2dha2ksIEtlbmljaGkNCj4gt6LLzcqxvOQ6IDIwMTbE 6jTUwjE5yNUgMTA6MTINCj4gytW8/sjLOiAnQmVub2l0IENsYWlzZSc7IGwzc21AaWV0Zi5vcmcN Cj4gs63LzToga3Jpc3RpYW4ubGFyc3NvbkB0LXN5c3RlbXMuc2U7IE1hcnRpbi5BZGFtc0B0ZWxl a29tLmRlOyAnTWlrYWVsIEFicmFoYW1zc29uJzsgJ0lhbiBGYXJyZXInOyAnWm9yaWMsIFNsYWRq YW5hJw0KPiDW98ziOiBSZTogW0wzc21dIEZlZWRiYWNrIG9uIGRyYWZ0LWlldGYtbDNzbS1sM3Zw bi1zZXJ2aWNlLW1vZGVsDQo+DQo+IEhpIEFsbCwNCj4NCj4+IFNob3VsZCB3ZSBkZWNsYXJlIGRl dmlhdGlvbnM/IEkgc3VwcG9zZSB3ZSBjYW4gYWx3YXlzIHJldHVybiBhbiBlcnJvcg0KPj4gd2hl biB0aGUgY3VzdG9tZXIgc2VuZHMgdGhpcyB0byB1cywgYnV0IHRoYXQncyBub3QgdmVyeSBlbGVn YW50IHRvIGRvDQo+PiBpbiBhIG1vZGVsIGRyaXZlbiB3b3JsZC4gSW50cm9kdWNpbmcgaWYtZmVh dHVyZSBpbnRvIHRoZSBtb2RlbCB3b3VsZCBwZXJoYXBzIGJlIG9uZSB3YXksIG9yIHRoYXQgdGhl IG1vZGVsIGJlIGNhcnZlZCB1cCBpbnRvIG1hbnkgc21hbGxlciBtb2RlbHMgdGhhdCBhdWdtZW50 cyBiYXNlIG1vZGVsLCBmb3IgZXhhbXBsZToNCj4NCj4gSW4gbXkgdW5kZXJzdGFuZGluZywgdGhl IGRldmlhdGlvbiBzdWl0cyB0aGlzLg0KPiAoSWYtKWZlYXR1cmUgaXMgdXNlZCBmb3IgYSBjb25k aXRpb25hbCBjYXNlLCBleC4pIGFuIGVxdWlwbWVudCBpbiBhIG5ldHdvcmsgc3VwcG9ydHMgYm90 aCBCR1AgYW5kIE9TUEYsIGJ1dCBhbm90aGVyIG9uZSBpbiB0aGUgc2FtZSBuZXR3b3JrIGNhbiBz dXBwb3J0IG9ubHkgQkdQLg0KPg0KPiBDb25mb3JtYW5jZSBmb3IgdGhlIGRldmlhdGlvbiBjYW4g YmUgY2hlY2tlZCBpbiB0aGUgbmVnb3RpYXRpb24gcGhhc2UsIGJlZm9yZSBhIGN1c3RvbWVyIHNl bmQgYW4gYWN0dWFsIHNlcnZpY2UgYWN0aXZhdGlvbiByZXF1ZXN0Lg0KPiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjAyMCNzZWN0aW9uLTUuNi40DQo+IFRoaXMgaXMgb3V0IG9mIHNj b3BlIGZvciBlYWNoIGRhdGEgbW9kZWwsIGJ1dCB0aGUgdHJhbnNwb3J0IHByb3RvY29sIG9yIFlB Tkcgc2hvdWxkIGNvbnNpZGVyIHRoaXMgKGFuZCBpcyBhbHJlYWR5IGNvbnNpZGVyZWQpLg0KPg0K PiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KPg0KPiBBbGwgdGhlIGJlc3QsDQo+IEtlbmljaGkN Cj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTDNzbSBbbWFpbHRvOmwz c20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbm9pdCBDbGFpc2UNCj4gU2VudDog TW9uZGF5LCBBcHJpbCAxOCwgMjAxNiA3OjQ0IFBNDQo+IFRvOiBsM3NtQGlldGYub3JnDQo+IENj OiBJYW4gRmFycmVyOyAnTWlrYWVsIEFicmFoYW1zc29uJzsga3Jpc3RpYW4ubGFyc3NvbkB0LXN5 c3RlbXMuc2U7IFpvcmljLCBTbGFkamFuYTsgTWFydGluLkFkYW1zQHRlbGVrb20uZGUNCj4gU3Vi amVjdDogW0wzc21dIEZlZWRiYWNrIG9uIGRyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1v ZGVsDQo+DQo+IERlYXIgYWxsLA0KPg0KPiBGZWVkYmFjayBmcm9tIEtyaXN0aWFuIExhcnNzb24s IGZvcndhcmRlZCB3aXRoIHBlcm1pc3Npb24uDQo+DQo+IFJlZ2FyZHMsIEJlbm9pdA0KPg0KPiA9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCj4NCj4gQmVub2l0LA0KPg0KPiBpbiBteSBoZWFkIHRoaXMgbW9kZWwgaXMgdXNlZCBu b3Qgb25seSBhcyBhbiBpbnRlcm5hbCByZXByZXNlbnRhdGlvbiBidXQgYWxzbyB0byBhbGxvdyBh IGN1c3RvbWVyIHRvIG1hbmFnZSBhIEwzVlBOIHRoYXQgd2UgKG9yIHNvbWVvbmUgZWxzZSkgcHJv dmlkZXMuIEkgd29uZGVyIGhvdyB3ZSBhcyB0aGUgcHJvdmlkZXIgY2FuIGxpbWl0IHRoZSBhbW91 bnQgb2YgZmVhdHVyZXMgdGhhdCB3ZSBzdXBwb3J0LiBUaGUgbW9kZWwgaW5jbHVkZXMgUklQLCBP U1BGIGFuZCBCR1AgYXMgUEUtQ0UgcHJvdG9jb2xzLiBUaGVyZSBhcmUgbXVsdGljYXN0IHBvcnRp b25zIGluIHRoZXJlIGFuZCBzbyBmb3J0aC4gSWYgd2UgY2hvb3NlIHRvIG9ubHkgcHJvdmlkZSBC R1AgYXMgcm91dGluZyBwcm90b2NvbCwgaG93IGNhbiB3ZSBzaWduYWwgdGhpcyB0byB0aGUgY3Vz dG9tZXI/IFNob3VsZCB3ZSBkZWNsYXJlIGRldmlhdGlvbnM/IEkgc3VwcG9zZSB3ZSBjYW4gYWx3 YXlzIHJldHVybiBhbiBlcnJvciB3aGVuIHRoZSBjdXN0b21lciBzZW5kcyB0aGlzIHRvIHVzLCBi dXQgdGhhdCdzIG5vdCB2ZXJ5IGVsZWdhbnQgdG8gZG8gaW4gYSBtb2RlbCBkcml2ZW4gd29ybGQu IEludHJvZHVjaW5nIGlmLWZlYXR1cmUgaW50byB0aGUgbW9kZWwgd291bGQgcGVyaGFwcyBiZSBv bmUgd2F5LCBvciB0aGF0IHRoZSBtb2RlbCBiZSBjYXJ2ZWQgdXAgaW50byBtYW55IHNtYWxsZXIg bW9kZWxzIHRoYXQgYXVnbWVudHMgYmFzZSBtb2RlbCwgZm9yIGV4YW1wbGU6DQo+ICAgICAgLSBs M3Zwbi1iYXNlDQo+ICAgICAgLSBsM3Zwbi1iZ3ANCj4gICAgICAtIGwzdnBuLXJpcA0KPiAgICAg IC0gbDN2cG4tb3NwZg0KPg0KPiBJZiB3ZSBvbmx5IHN1cHBvcnQgQkdQIHRoZW4gd2Ugd291bGQg aW1wbGVtZW50IHRoZSBsM3Zwbi1iYXNlIG1vZGVsIGFuZCBsM3Zwbi1iZ3AgKHdoaWNoIGF1Z21l bnRzIGJhc2UpLiBDdXN0b21lcnMgY2FuIGNsZWFybHkgc2VlIHdoYXQgd2Ugc3VwcG9ydCBieSBs b29raW5nIGF0IHRoZSBuZXRjb25mIGNhcGFiaWxpdGllcyBvZiBvdXIgb3JjaGVzdHJhdGlvbiBz eXN0ZW0uDQo+DQo+IEFwb2xvZ2llcyBpZiBJIG1pc3NlZCBzb21ldGhpbmcgaW4gdGhlIG1vZGVs LCBpdCdzIGEgeWVhciBhZ28gc2luY2UgSSByZWFkIGl0IGFuZCBJJ3ZlIG9ubHkgc2tpbW1lZCB0 aHJvdWdoIHRoZSBsYXRlc3QgcmV2aXNpb24uDQo+DQo+IEtpbmQgcmVnYXJkcywNCj4gICAgICAg IEtyaXN0aWFuLg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBMM3NtIG1haWxpbmcgbGlzdA0KPiBMM3NtQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbQ0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMM3NtIG1haWxpbmcgbGlzdA0KPiBM M3NtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNz bQ0KPg== From nobody Tue Apr 19 04:57:33 2016 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 CB52412DA21 for ; Tue, 19 Apr 2016 04:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 djDPv66DvGyy for ; Tue, 19 Apr 2016 04:57:28 -0700 (PDT) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36F312D66B for ; Tue, 19 Apr 2016 04:57:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 546F0261846; Tue, 19 Apr 2016 13:57:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIjhUIQEouQL; Tue, 19 Apr 2016 13:57:25 +0200 (CEST) Received: from Kristians-MacBook-Pro.local (h-161-130.a515.priv.bahnhof.se [155.4.161.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 3248E26180E; Tue, 19 Apr 2016 13:57:25 +0200 (CEST) To: stephane.litkowski@orange.com, "Ogaki, Kenichi" , 'Benoit Claise' , "l3sm@ietf.org" References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5715E4F4.6090303@spritelink.net> <15600_1461060809_571604C9_15600_294_1_9E32478DFA9976438E7A22F69B08FF921BB059BF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Kristian Larsson Message-ID: <57161D24.6060300@spritelink.net> Date: Tue, 19 Apr 2016 13:57:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <15600_1461060809_571604C9_15600_294_1_9E32478DFA9976438E7A22F69B08FF921BB059BF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "'Zoric, Sladjana'" , 'Mikael Abrahamsson' , 'Ian Farrer' , "Martin.Adams@telekom.de" Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 11:57:31 -0000 On 19/04/16 12:13, stephane.litkowski@orange.com wrote: > The main issue with features is to define what should be a feature , > and what is in the base and I'm afraid that we could fall in infinite > discussions. Okay, sure, I can see how that is a non-trivial discussion but it's certainly not an impossible one. Instead you are advocating for the extreme opposite and not have any if-features at all, which results in a model so big that I will have to spend more time writing a deviation file for it than it would take me to write a new model. Okay, I'm exaggerating a bit but virtually all providers will define a deviation which I think means the model is fundamentally broken. Having deviations shouldn't be the normal state. Does Orange support all those PE-CE protocols? Do you do encryption? Will you not have any deviations? Kind regards, Kristian. From nobody Tue Apr 19 05:17:09 2016 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 BBD0E12ED5A for ; Tue, 19 Apr 2016 05:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 t_pMLGvLwJ82 for ; Tue, 19 Apr 2016 05:17:06 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C013F12EAE3 for ; Tue, 19 Apr 2016 05:17:05 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 7DDF520158; Tue, 19 Apr 2016 14:17:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 42225120065; Tue, 19 Apr 2016 14:17:04 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0279.002; Tue, 19 Apr 2016 14:17:03 +0200 From: To: Kristian Larsson , "Ogaki, Kenichi" , 'Benoit Claise' , "l3sm@ietf.org" Thread-Topic: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHRmV8v5MUcs4/sNkyHy/KxHn2YC5+QbY6AgAB7CxD//+VsAIAARvLw///8CQCAACMiYA== Date: Tue, 19 Apr 2016 12:17:03 +0000 Message-ID: <9842_1461068224_571621C0_9842_459_1_9E32478DFA9976438E7A22F69B08FF921BB05AA2@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5715E4F4.6090303@spritelink.net> <15600_1461060809_571604C9_15600_294_1_9E32478DFA9976438E7A22F69B08FF921BB059BF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <57161D24.6060300@spritelink.net> In-Reply-To: <57161D24.6060300@spritelink.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/mixed; boundary="_002_9E32478DFA9976438E7A22F69B08FF921BB05AA2OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Cc: "'Zoric, Sladjana'" , 'Mikael Abrahamsson' , 'Ian Farrer' , "Martin.Adams@telekom.de" Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 12:17:08 -0000 --_002_9E32478DFA9976438E7A22F69B08FF921BB05AA2OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We will not support all containers of the model but most of them. Now in term of model usage, two main usages : - customer is using a portal to order the services, in this case there is n= o need to advertise any deviation, as the REST or Netconf client is also ma= naged by the provider (client is the portal) - Provider opens API to customers : - customer is able to use directly L3SM using REST or Netconf : deviations= need to be advertised. You will find attached a quick exercise (so I probably missed some) on what= could be the features in the model tree. Features are identified between {= }. For some identities, we would need features : YANG 1.1 needed. Just to start the discussion. Best Regards, Stephane -----Original Message----- From: Kristian Larsson [mailto:kristian@spritelink.net]=20 Sent: Tuesday, April 19, 2016 13:57 To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; l3sm@iet= f.org Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sl= adjana' Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model On 19/04/16 12:13, stephane.litkowski@orange.com wrote: > The main issue with features is to define what should be a feature ,=20 > and what is in the base and I'm afraid that we could fall in infinite=20 > discussions. Okay, sure, I can see how that is a non-trivial discussion but it's certain= ly not an impossible one. Instead you are advocating for the extreme opposi= te and not have any if-features at all, which results in a model so big tha= t I will have to spend more time writing a deviation file for it than it wo= uld take me to write a new model. Okay, I'm exaggerating a bit but virtuall= y all providers will define a deviation which I think means the model is fu= ndamentally broken. Having deviations shouldn't be the normal state. Does Orange support all those PE-CE protocols? Do you do encryption?=20 Will you not have any deviations? Kind regards, Kristian. ___________________________________________________________________________= ______________________________________________ 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. --_002_9E32478DFA9976438E7A22F69B08FF921BB05AA2OPEXCLILMA4corp_ Content-Type: application/octet-stream; name="ietf-l3vpn-svc with features.tree" Content-Description: ietf-l3vpn-svc with features.tree Content-Disposition: attachment; filename="ietf-l3vpn-svc with features.tree"; size=10212; creation-date="Tue, 19 Apr 2016 12:12:01 GMT"; modification-date="Tue, 19 Apr 2016 12:15:07 GMT" Content-Transfer-Encoding: base64 bW9kdWxlOiBpZXRmLWwzdnBuLXN2YwogICArLS1ydyBsM3Zwbi1zdmMKICAgICAgKy0tcncgdnBu LXNlcnZpY2VzCiAgICAgIHwgICstLXJ3IHZwbi1zdmMqIFt2cG4taWRdCiAgICAgIHwgICAgICst LXJ3IHZwbi1pZCAgICAgICAgICAgICAgICAgICBzdmMtaWQKICAgICAgfCAgICAgKy0tcncgY3Vz dG9tZXItbmFtZT8gICAgICAgICAgIHN0cmluZwogICAgICB8ICAgICArLS1ydyB0b3BvbG9neT8g ICAgICAgICAgICAgICAgaWRlbnRpdHlyZWYKICAgICAgfCAgICAgKy0tcncgY2xvdWQtYWNjZXNz KiBbY2xvdWQtaWRlbnRpZmllcl0ge2Nsb3VkLWFjY2Vzc30KICAgICAgfCAgICAgfCAgKy0tcncg Y2xvdWQtaWRlbnRpZmllciAgICAgICAgc3RyaW5nCiAgICAgIHwgICAgIHwgICstLXJ3IGF1dGhv cml6ZWQtc2l0ZXMqIFtzaXRlLWlkXQogICAgICB8ICAgICB8ICB8ICArLS1ydyBzaXRlLWlkICAg IGxlYWZyZWYKICAgICAgfCAgICAgfCAgKy0tcncgZGVuaWVkLXNpdGVzKiBbc2l0ZS1pZF0KICAg ICAgfCAgICAgfCAgfCAgKy0tcncgc2l0ZS1pZCAgICBsZWFmcmVmCiAgICAgIHwgICAgIHwgICst LXJ3IG5hdC1lbmFibGVkPyAgICAgICAgICAgIGJvb2xlYW4KICAgICAgfCAgICAgfCAgKy0tcncg Y3VzdG9tZXItbmF0LWFkZHJlc3M/ICAgaW5ldDppcHY0LWFkZHJlc3MKICAgICAgfCAgICAgKy0t cncgbXVsdGljYXN0IHttdWx0aWNhc3R9CiAgICAgIHwgICAgIHwgICstLXJ3IGVuYWJsZWQ/ICAg ICAgICAgICAgICAgICBib29sZWFuCiAgICAgIHwgICAgIHwgICstLXJ3IGN1c3RvbWVyLXRyZWUt Zmxhdm9ycwogICAgICB8ICAgICB8ICB8ICArLS1ydyB0cmVlLWZsYXZvciogW3R5cGVdCiAgICAg IHwgICAgIHwgIHwgICAgICstLXJ3IHR5cGUgICAgaWRlbnRpdHlyZWYKICAgICAgfCAgICAgfCAg Ky0tcncgcnAKICAgICAgfCAgICAgfCAgICAgKy0tcncgcnAtZ3JvdXAtbWFwcGluZyogW3JwLWFk ZHJlc3MgZ3JvdXBdCiAgICAgIHwgICAgIHwgICAgIHwgICstLXJ3IHByb3ZpZGVyLW1hbmFnZWQg e3Byb3ZpZGVyLW1hbmFnZWQtcnB9CiAgICAgIHwgICAgIHwgICAgIHwgIHwgICstLXJ3IGVuYWJs ZWQ/ICAgICAgYm9vbGVhbgogICAgICB8ICAgICB8ICAgICB8ICB8ICArLS1ydyBhbnljYXN0LXJw PyAgIGJvb2xlYW4KICAgICAgfCAgICAgfCAgICAgfCAgKy0tcncgcnAtYWRkcmVzcyAgICAgICAg ICB1bmlvbgogICAgICB8ICAgICB8ICAgICB8ICArLS1ydyBncm91cCAgICAgICAgICAgICAgIHVu aW9uCiAgICAgIHwgICAgIHwgICAgICstLXJ3IHJwLWRpc2NvdmVyeT8gICAgICAgaWRlbnRpdHly ZWYKICAgICAgfCAgICAgKy0tcncgbXBscz8gICAgICAgICAgICAgICAgICAgIGJvb2xlYW4ge21w bHN9CiAgICAgIHwgICAgICstLXJ3IHRyYW5zcG9ydC1jb25zdHJhaW50cyB7dHJhZmZpYy1lbmdp bmVlcmluZ30KICAgICAgfCAgICAgfCAgKy0tcncgdW5pY2FzdC10cmFuc3BvcnQtY29uc3RyYWlu dHMKICAgICAgfCAgICAgfCAgfCAgKy0tcncgY29uc3RyYWludHMqIFtjb25zdHJhaW50LWlkXQog ICAgICB8ICAgICB8ICB8ICAgICArLS1ydyBjb25zdHJhaW50LWlkICAgICAgc3ZjLWlkCiAgICAg IHwgICAgIHwgIHwgICAgICstLXJ3IHNpdGUxPyAgICAgICAgICAgICBzdmMtaWQKICAgICAgfCAg ICAgfCAgfCAgICAgKy0tcncgc2l0ZTI/ICAgICAgICAgICAgIHN2Yy1pZAogICAgICB8ICAgICB8 ICB8ICAgICArLS1ydyBjb25zdHJhaW50LWxpc3QqIFtjb25zdHJhaW50LXR5cGVdCiAgICAgIHwg ICAgIHwgIHwgICAgICAgICstLXJ3IGNvbnN0cmFpbnQtdHlwZSAgICAgICAgICAgIGlkZW50aXR5 cmVmCiAgICAgIHwgICAgIHwgIHwgICAgICAgICstLXJ3IGNvbnN0cmFpbnQtb3BhcXVlLXZhbHVl PyAgIHN0cmluZwogICAgICB8ICAgICB8ICArLS1ydyBtdWx0aWNhc3QtdHJhbnNwb3J0LWNvbnN0 cmFpbnRzIHt0cmFmZmljLWVuZ2luZWVyaW5nLW11bHRpY2FzdH0KICAgICAgfCAgICAgfCAgICAg Ky0tcncgY29uc3RyYWludHMqIFtjb25zdHJhaW50LWlkXQogICAgICB8ICAgICB8ICAgICAgICAr LS1ydyBjb25zdHJhaW50LWlkICAgICAgc3ZjLWlkCiAgICAgIHwgICAgIHwgICAgICAgICstLXJ3 IHNyYy1zaXRlPyAgICAgICAgICBzdmMtaWQKICAgICAgfCAgICAgfCAgICAgICAgKy0tcncgZHN0 LXNpdGU/ICAgICAgICAgIHN2Yy1pZAogICAgICB8ICAgICB8ICAgICAgICArLS1ydyBjb25zdHJh aW50LWxpc3QqIFtjb25zdHJhaW50LXR5cGVdCiAgICAgIHwgICAgIHwgICAgICAgICAgICstLXJ3 IGNvbnN0cmFpbnQtdHlwZSAgICAgICAgICAgIGlkZW50aXR5cmVmCiAgICAgIHwgICAgIHwgICAg ICAgICAgICstLXJ3IGNvbnN0cmFpbnQtb3BhcXVlLXZhbHVlPyAgIHN0cmluZwogICAgICB8ICAg ICArLS1ydyBleHRyYW5ldC12cG5zIHtleHRyYW5ldH0KICAgICAgfCAgICAgICAgKy0tcncgZXh0 cmFuZXQtdnBuKiBbdnBuLWlkXQogICAgICB8ICAgICAgICAgICArLS1ydyB2cG4taWQgICAgICAg ICAgICAgIHN2Yy1pZAogICAgICB8ICAgICAgICAgICArLS1ydyBsb2NhbC1zaXRlcy1yb2xlPyAg IGlkZW50aXR5cmVmCiAgICAgICstLXJ3IHNpdGVzCiAgICAgIHwgICstLXJ3IHNpdGUqIFtzaXRl LWlkXQogICAgICB8ICAgICArLS1ydyBzaXRlLWlkICAgICAgICAgICAgICAgICAgc3ZjLWlkCiAg ICAgIHwgICAgICstLXJ3IGFwcGx5LXRlbXBsYXRlPyAgICAgICAgICBsZWFmcmVmCiAgICAgIHwg ICAgICstLXJ3IHJlcXVlc3RlZC1zaXRlLXN0YXJ0PyAgICB5YW5nOmRhdGUtYW5kLXRpbWUKICAg ICAgfCAgICAgKy0tcncgcmVxdWVzdGVkLXNpdGUtc3RvcD8gICAgIHlhbmc6ZGF0ZS1hbmQtdGlt ZQogICAgICB8ICAgICArLS1ydyBhY3R1YWwtc2l0ZS1zdGFydD8gICAgICAgeWFuZzpkYXRlLWFu ZC10aW1lCiAgICAgIHwgICAgICstLXJ3IGFjdHVhbC1zaXRlLXN0b3A/ICAgICAgICB5YW5nOmRh dGUtYW5kLXRpbWUKICAgICAgfCAgICAgKy0tcncgbG9jYXRpb24KICAgICAgfCAgICAgfCAgKy0t cncgYWRkcmVzcz8gICAgICAgIHN0cmluZwogICAgICB8ICAgICB8ICArLS1ydyB6aXAtY29kZT8g ICAgICAgc3RyaW5nCiAgICAgIHwgICAgIHwgICstLXJ3IGNpdHk/ICAgICAgICAgICBzdHJpbmcK ICAgICAgfCAgICAgfCAgKy0tcncgY291bnRyeS1jb2RlPyAgIHN0cmluZwogICAgICB8ICAgICAr LS1ydyBzaXRlLWRpdmVyc2l0eSB7c2l0ZS1kaXZlcnNpdHl9CiAgICAgIHwgICAgIHwgICstLXJ3 IHR5cGU/ICAgICAgICAgcGxhY2VtZW50LWRpdmVyc2l0eSB7bmVlZCBhIGZlYXR1cmUgaGVyZSA9 PiBZQU5HMS4xfQogICAgICB8ICAgICB8ICArLS1ydyBzaXRlLWdyb3VwKiAgIHVpbnQzMgogICAg ICB8ICAgICArLS1ydyBtYW5hZ2VtZW50CiAgICAgIHwgICAgIHwgICstLXJ3IHR5cGU/ICAgICAg ICAgICAgICAgICAgIGlkZW50aXR5cmVmIHtuZWVkIGEgZmVhdHVyZSBoZXJlID0+IFlBTkcxLjF9 CiAgICAgIHwgICAgIHwgICstLXJ3IG1hbmFnZW1lbnQtdHJhbnNwb3J0PyAgIGlkZW50aXR5cmVm IHtuZWVkIGEgZmVhdHVyZSBoZXJlID0+IFlBTkcxLjF9CiAgICAgIHwgICAgIHwgICstLXJ3IGFk ZHJlc3M/ICAgICAgICAgICAgICAgIHVuaW9uCiAgICAgIHwgICAgICstLXJ3IHZwbi1wb2xpY3kt bGlzdAogICAgICB8ICAgICB8ICArLS1ydyB2cG4tcG9saWN5KiBbdnBuLXBvbGljeS1pZF0KICAg ICAgfCAgICAgfCAgICAgKy0tcncgdnBuLXBvbGljeS1pZCAgICBzdmMtaWQKICAgICAgfCAgICAg fCAgICAgKy0tcncgZW50cmllcyogW2lkXQogICAgICB8ICAgICB8ICAgICAgICArLS1ydyBpZCAg ICAgICAgc3ZjLWlkCiAgICAgIHwgICAgIHwgICAgICAgICstLXJ3IGZpbHRlcgogICAgICB8ICAg ICB8ICAgICAgICB8ICArLS1ydyAobGFuKT8KICAgICAgfCAgICAgfCAgICAgICAgfCAgICAgICAg Li4uCiAgICAgIHwgICAgIHwgICAgICAgICstLXJ3IHZwbgogICAgICB8ICAgICB8ICAgICAgICAg ICArLS1ydyB2cG4taWQgICAgICAgbGVhZnJlZgogICAgICB8ICAgICB8ICAgICAgICAgICArLS1y dyBzaXRlLXJvbGUgICAgaWRlbnRpdHlyZWYKICAgICAgfCAgICAgKy0tcncgc2l0ZS12cG4tZmxh dm9yPyAgICAgICAgIGlkZW50aXR5cmVmIHtuZWVkIGEgZmVhdHVyZSBoZXJlID0+IFlBTkcxLjF9 CiAgICAgIHwgICAgICstLXJ3IG1heGltdW0tcm91dGVzCiAgICAgIHwgICAgIHwgICstLXJ3IGFk ZHJlc3MtZmFtaWx5KiBbYWZdCiAgICAgIHwgICAgIHwgICAgICstLXJ3IGFmICAgICAgICAgICAg ICAgIGlkZW50aXR5cmVmCiAgICAgIHwgICAgIHwgICAgICstLXJ3IG1heGltdW0tcm91dGVzPyAg IHVpbnQzMgogICAgICB8ICAgICArLS1ydyBzZWN1cml0eSB7c2VjdXJpdHl9CiAgICAgIHwgICAg IHwgICstLXJ3IGF1dGhlbnRpY2F0aW9uCiAgICAgIHwgICAgIHwgICstLXJ3IGVuY3J5cHRpb24K ICAgICAgfCAgICAgfCAgICAgKy0tcncgZW5hYmxlZD8gICAgICAgICAgICAgIGJvb2xlYW4KICAg ICAgfCAgICAgfCAgICAgKy0tcncgbGF5ZXI/ICAgICAgICAgICAgICAgIGVudW1lcmF0aW9uCiAg ICAgIHwgICAgIHwgICAgICstLXJ3IGVuY3J5cHRpb24tcHJvZmlsZQogICAgICB8ICAgICB8ICAg ICAgICArLS1ydyAocHJvZmlsZSk/CiAgICAgIHwgICAgIHwgICAgICAgICAgICstLToocHJvdmlk ZXItcHJvZmlsZSkge3NlY3VyaXR5LWVuY3J5cHRpb24tc3RkfQogICAgICB8ICAgICB8ICAgICAg ICAgICB8ICAgICAuLi4KICAgICAgfCAgICAgfCAgICAgICAgICAgKy0tOihjdXN0b21lci1wcm9m aWxlKSB7c2VjdXJpdHktZW5jcnlwdGlvbi1wcm92aWRlcn0KICAgICAgfCAgICAgfCAgICAgICAg ICAgICAgICAgLi4uCiAgICAgIHwgICAgICstLXJ3IHNlcnZpY2UKICAgICAgfCAgICAgfCAgKy0t cncgc3ZjLWlucHV0LWJhbmR3aWR0aD8gICAgdWludDMyCiAgICAgIHwgICAgIHwgICstLXJ3IHN2 Yy1vdXRwdXQtYmFuZHdpZHRoPyAgIHVpbnQzMgogICAgICB8ICAgICB8ICArLS1ydyBzdmMtbXR1 PyAgICAgICAgICAgICAgICB1aW50MTYKICAgICAgfCAgICAgfCAgKy0tcncgcW9zIHtxb3N9CiAg ICAgIHwgICAgIHwgIHwgICstLXJ3IHFvcy1jbGFzc2lmaWNhdGlvbi1wb2xpY3kKICAgICAgfCAg ICAgfCAgfCAgfCAgKy0tcncgcnVsZXMqIFtpZF0KICAgICAgfCAgICAgfCAgfCAgfCAgICAgKy0t cncgaWQgICAgICAgICAgICAgICAgIHVpbnQxNgogICAgICB8ICAgICB8ICB8ICB8ICAgICArLS1y dyBtYXRjaC1mbG93CiAgICAgIHwgICAgIHwgIHwgIHwgICAgIHwgICAgIC4uLgogICAgICB8ICAg ICB8ICB8ICB8ICAgICArLS1ydyB0YXJnZXQtY2xhc3MtaWQ/ICAgc3RyaW5nCiAgICAgIHwgICAg IHwgIHwgICstLXJ3IHFvcy1wcm9maWxlCiAgICAgIHwgICAgIHwgIHwgICAgICstLXJ3IChxb3Mt cHJvZmlsZSk/CiAgICAgIHwgICAgIHwgIHwgICAgICAgICstLTooc3RhbmRhcmQpCiAgICAgIHwg ICAgIHwgIHwgICAgICAgIHwgICAgIC4uLgogICAgICB8ICAgICB8ICB8ICAgICAgICArLS06KGN1 c3RvbSkge3Fvcy1jdXN0b219CiAgICAgIHwgICAgIHwgIHwgICAgICAgICAgICAgIC4uLgogICAg ICB8ICAgICB8ICArLS1ydyBtcGxzIHttcGxzfQogICAgICB8ICAgICB8ICB8ICArLS1ydyBzaWdu YWxsaW5nLXR5cGU/ICAgZW51bWVyYXRpb24KICAgICAgfCAgICAgfCAgKy0tcncgbXVsdGljYXN0 IHttdWx0aWNhc3R9CiAgICAgIHwgICAgIHwgICAgICstLXJ3IG11bHRpY2FzdC1zaXRlLXR5cGU/ ICAgICAgICAgICAgZW51bWVyYXRpb24KICAgICAgfCAgICAgfCAgICAgKy0tcncgbXVsdGljYXN0 LXRyYW5zcG9ydC1wcm90b2NvbAogICAgICB8ICAgICB8ICAgICB8ICArLS1ydyBpcHY0PyAgIGJv b2xlYW4KICAgICAgfCAgICAgfCAgICAgfCAgKy0tcncgaXB2Nj8gICBib29sZWFuIHttdWx0aWNh c3QtaXB2Nn0KICAgICAgfCAgICAgfCAgICAgKy0tcncgcHJvdG9jb2wtdHlwZT8gICAgICAgICAg ICAgICAgICBlbnVtZXJhdGlvbgogICAgICB8ICAgICArLS1ydyByb3V0aW5nLXByb3RvY29scwog ICAgICB8ICAgICB8ICArLS1ydyByb3V0aW5nLXByb3RvY29sKiBbdHlwZV0KICAgICAgfCAgICAg fCAgICAgKy0tcncgdHlwZSAgICAgIGlkZW50aXR5cmVmCiAgICAgIHwgICAgIHwgICAgICstLXJ3 IG9zcGYge3J0Zy1vc3BmfQogICAgICB8ICAgICB8ICAgICB8ICArLS1ydyBhZGRyZXNzLWZhbWls eSogICBpZGVudGl0eXJlZiB7bmVlZCBhIGZlYXR1cmUgaGVyZSA9PiBZQU5HMS4xfQogICAgICB8 ICAgICB8ICAgICB8ICArLS1ydyBhcmVhLWFkZHJlc3M/ICAgICB5YW5nOmRvdHRlZC1xdWFkCiAg ICAgIHwgICAgIHwgICAgIHwgICstLXJ3IG1ldHJpYz8gICAgICAgICAgIHVpbnQxNgogICAgICB8 ICAgICB8ICAgICB8ICArLS1ydyBzaGFtLWxpbmsqIFt0YXJnZXQtc2l0ZV0KICAgICAgfCAgICAg fCAgICAgfCAgICAgKy0tcncgdGFyZ2V0LXNpdGUgICAgc3ZjLWlkCiAgICAgIHwgICAgIHwgICAg IHwgICAgICstLXJ3IG1ldHJpYz8gICAgICAgIHVpbnQxNgogICAgICB8ICAgICB8ICAgICArLS1y dyBiZ3Age3J0Zy1iZ3B9CiAgICAgIHwgICAgIHwgICAgIHwgICstLXJ3IGF1dG9ub21vdXMtc3lz dGVtPyAgIHVpbnQzMgogICAgICB8ICAgICB8ICAgICB8ICArLS1ydyBhZGRyZXNzLWZhbWlseSog ICAgICBpZGVudGl0eXJlZiB7bmVlZCBhIGZlYXR1cmUgaGVyZSA9PiBZQU5HMS4xfQogICAgICB8 ICAgICB8ICAgICArLS1ydyBzdGF0aWMKICAgICAgfCAgICAgfCAgICAgfCAgKy0tcncgY2FzY2Fk ZWQtbGFuLXByZWZpeGVzCiAgICAgIHwgICAgIHwgICAgIHwgICAgICstLXJ3IGlwdjQtbGFuLXBy ZWZpeGVzKiBbbGFuIG5leHQtaG9wXQogICAgICB8ICAgICB8ICAgICB8ICAgICB8ICAgICAuLi4K ICAgICAgfCAgICAgfCAgICAgfCAgICAgKy0tcncgaXB2Ni1sYW4tcHJlZml4ZXMqIFtsYW4gbmV4 dC1ob3BdIHtpcHY2fQogICAgICB8ICAgICB8ICAgICB8ICAgICAgICAgICAuLi4KICAgICAgfCAg ICAgfCAgICAgKy0tcncgcmlwIHtydGctcmlwfQogICAgICB8ICAgICB8ICAgICB8ICArLS1ydyBh ZGRyZXNzLWZhbWlseSogICBpZGVudGl0eXJlZgogICAgICB8ICAgICB8ICAgICArLS1ydyB2cnJw IHtydGctdnJycH0KICAgICAgfCAgICAgfCAgICAgICAgKy0tcncgYWRkcmVzcy1mYW1pbHkqICAg aWRlbnRpdHlyZWYKICAgICAgfCAgICAgKy0tcncgc2l0ZS1uZXR3b3JrLWFjY2Vzc2VzCiAgICAg IHwgICAgICAgICstLXJ3IHNpdGUtbmV0d29yay1hY2Nlc3MqIFtzaXRlLW5ldHdvcmstYWNjZXNz LWlkXQogICAgICB8ICAgICAgICAgICArLS1ydyBzaXRlLW5ldHdvcmstYWNjZXNzLWlkICAgIHN2 Yy1pZAogICAgICB8ICAgICAgICAgICArLS1ydyBhcHBseS10ZW1wbGF0ZT8gICAgICAgICAgIGxl YWZyZWYKICAgICAgfCAgICAgICAgICAgKy0tcncgYWNjZXNzLWRpdmVyc2l0eQogICAgICB8ICAg ICAgICAgICB8ICArLS1ydyB0eXBlPyAgIHBsYWNlbWVudC1kaXZlcnNpdHkKICAgICAgfCAgICAg ICAgICAgKy0tcncgYmVhcmVyCiAgICAgIHwgICAgICAgICAgIHwgICstLXJ3IHR5cGU/ICAgICAg ICAgICAgICAgc3RyaW5nCiAgICAgIHwgICAgICAgICAgIHwgICstLXJ3IGJlYXJlci1yZWZlcmVu Y2U/ICAgc3RyaW5nCiAgICAgIHwgICAgICAgICAgICstLXJ3IGlwLWNvbm5lY3Rpb24KICAgICAg fCAgICAgICAgICAgfCAgKy0tcncgaXB2NAogICAgICB8ICAgICAgICAgICB8ICB8ICArLS1ydyBh ZGRyZXNzLWFsbG9jYXRpb24tdHlwZT8gICBpZGVudGl0eXJlZgogICAgICB8ICAgICAgICAgICB8 ICB8ICArLS1ydyAoc3VibmV0KT8KICAgICAgfCAgICAgICAgICAgfCAgfCAgICAgICAgLi4uCiAg ICAgIHwgICAgICAgICAgIHwgICstLXJ3IGlwdjYge2lwdjZ9CiAgICAgIHwgICAgICAgICAgIHwg IHwgICstLXJ3IGFkZHJlc3MtYWxsb2NhdGlvbi10eXBlPyAgIHN0cmluZwogICAgICB8ICAgICAg ICAgICB8ICB8ICArLS1ydyAoc3VibmV0KT8KICAgICAgfCAgICAgICAgICAgfCAgfCAgICAgICAg Li4uCiAgICAgIHwgICAgICAgICAgIHwgICstLXJ3IG9hbQogICAgICB8ICAgICAgICAgICB8ICAg ICArLS1ydyBiZmQKICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICAgLi4uCiAgICAgIHwgICAg ICAgICAgICstLXJ3IHNlY3VyaXR5IHtzZWN1cml0eX0KICAgICAgfCAgICAgICAgICAgfCAgKy0t cncgYXV0aGVudGljYXRpb24KICAgICAgfCAgICAgICAgICAgfCAgKy0tcncgZW5jcnlwdGlvbgog ICAgICB8ICAgICAgICAgICB8ICAgICArLS1ydyBlbmFibGVkPyAgICAgICAgICAgICAgYm9vbGVh bgogICAgICB8ICAgICAgICAgICB8ICAgICArLS1ydyBsYXllcj8gICAgICAgICAgICAgICAgZW51 bWVyYXRpb24KICAgICAgfCAgICAgICAgICAgfCAgICAgKy0tcncgZW5jcnlwdGlvbi1wcm9maWxl CiAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIC4uLgogICAgICB8ICAgICAgICAgICArLS1y dyBzZXJ2aWNlCiAgICAgIHwgICAgICAgICAgIHwgICstLXJ3IHN2Yy1pbnB1dC1iYW5kd2lkdGg/ ICAgIHVpbnQzMgogICAgICB8ICAgICAgICAgICB8ICArLS1ydyBzdmMtb3V0cHV0LWJhbmR3aWR0 aD8gICB1aW50MzIKICAgICAgfCAgICAgICAgICAgfCAgKy0tcncgc3ZjLW10dT8gICAgICAgICAg ICAgICAgdWludDE2CiAgICAgIHwgICAgICAgICAgIHwgICstLXJ3IHFvcwogICAgICB8ICAgICAg ICAgICB8ICB8ICArLS1ydyBxb3MtY2xhc3NpZmljYXRpb24tcG9saWN5CiAgICAgIHwgICAgICAg ICAgIHwgIHwgIHwgICAgIC4uLgogICAgICB8ICAgICAgICAgICB8ICB8ICArLS1ydyBxb3MtcHJv ZmlsZQogICAgICB8ICAgICAgICAgICB8ICB8ICAgICAgICAuLi4KICAgICAgfCAgICAgICAgICAg fCAgKy0tcncgbXBscyB7bXBsc30KICAgICAgfCAgICAgICAgICAgfCAgfCAgKy0tcncgc2lnbmFs bGluZy10eXBlPyAgIGVudW1lcmF0aW9uCiAgICAgIHwgICAgICAgICAgIHwgICstLXJ3IG11bHRp Y2FzdCB7bXVsdGljYXN0fQogICAgICB8ICAgICAgICAgICB8ICAgICArLS1ydyBtdWx0aWNhc3Qt c2l0ZS10eXBlPyAgICAgICAgICAgIGVudW1lcmF0aW9uCiAgICAgIHwgICAgICAgICAgIHwgICAg ICstLXJ3IG11bHRpY2FzdC10cmFuc3BvcnQtcHJvdG9jb2wKICAgICAgfCAgICAgICAgICAgfCAg ICAgfCAgICAgLi4uCiAgICAgIHwgICAgICAgICAgIHwgICAgICstLXJ3IHByb3RvY29sLXR5cGU/ ICAgICAgICAgICAgICAgICAgZW51bWVyYXRpb24KICAgICAgfCAgICAgICAgICAgKy0tcncgcm91 dGluZy1wcm90b2NvbHMKICAgICAgfCAgICAgICAgICAgfCAgKy0tcncgcm91dGluZy1wcm90b2Nv bCogW3R5cGVdCiAgICAgIHwgICAgICAgICAgIHwgICAgICstLXJ3IHR5cGUgICAgICBpZGVudGl0 eXJlZgogICAgICB8ICAgICAgICAgICB8ICAgICArLS1ydyBvc3BmIHtydGctb3NwZn0KICAgICAg fCAgICAgICAgICAgfCAgICAgfCAgICAgLi4uCiAgICAgIHwgICAgICAgICAgIHwgICAgICstLXJ3 IGJncCB7cnRnLWJncH19CiAgICAgIHwgICAgICAgICAgIHwgICAgIHwgICAgIC4uLgogICAgICB8 ICAgICAgICAgICB8ICAgICArLS1ydyBzdGF0aWMKICAgICAgfCAgICAgICAgICAgfCAgICAgfCAg ICAgLi4uCiAgICAgIHwgICAgICAgICAgIHwgICAgICstLXJ3IHJpcCB7cnRnLXJpcH0KICAgICAg fCAgICAgICAgICAgfCAgICAgfCAgICAgLi4uCiAgICAgIHwgICAgICAgICAgIHwgICAgICstLXJ3 IHZycnAge3J0Zy12cnJwfQogICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICAuLi4KICAgICAg fCAgICAgICAgICAgKy0tcncgYXZhaWxhYmlsaXR5IHthdmFpbGFiaWxpdHl9CiAgICAgIHwgICAg ICAgICAgIHwgICstLXJ3IHRyYWZmaWMtcHJvdGVjdGlvbiB7ZnJyfQogICAgICB8ICAgICAgICAg ICB8ICB8ICArLS1ydyBlbmFibGVkPyAgIGJvb2xlYW4KICAgICAgfCAgICAgICAgICAgfCAgKy0t cncgYWNjZXNzLXByaW9yaXR5PyAgICAgIHVpbnQzMgogICAgICB8ICAgICAgICAgICArLS1ydyB2 cG4tYXR0YWNobWVudAogICAgICB8ICAgICAgICAgICAgICArLS1ydyAoYXR0YWNobWVudC1mbGF2 b3IpPwogICAgICB8ICAgICAgICAgICAgICAgICArLS06KHZwbi1wb2xpY3ktaWQpCiAgICAgIHwg ICAgICAgICAgICAgICAgIHwgICAgIC4uLgogICAgICB8ICAgICAgICAgICAgICAgICArLS06KHZw bi1pZCkKICAg --_002_9E32478DFA9976438E7A22F69B08FF921BB05AA2OPEXCLILMA4corp_-- From nobody Tue Apr 19 07:35:46 2016 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 C436F12E733 for ; Tue, 19 Apr 2016 07:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 p_13OcjDsGPf for ; Tue, 19 Apr 2016 07:35:41 -0700 (PDT) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1AB12E7A1 for ; Tue, 19 Apr 2016 07:35:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id B0290261846; Tue, 19 Apr 2016 16:35:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2iY6bEbsM4u; Tue, 19 Apr 2016 16:35:37 +0200 (CEST) Received: from Kristians-MacBook-Pro.local (h-161-130.a515.priv.bahnhof.se [155.4.161.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 62C5426180E; Tue, 19 Apr 2016 16:35:37 +0200 (CEST) To: stephane.litkowski@orange.com, "Ogaki, Kenichi" , 'Benoit Claise' , "l3sm@ietf.org" References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5715E4F4.6090303@spritelink.net> <15600_1461060809_571604C9_15600_294_1_9E32478DFA9976438E7A22F69B08FF921BB059BF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <57161D24.6060300@spritelink.net> <9842_1461068224_571621C0_9842_459_1_9E32478DFA9976438E7A22F69B08FF921BB05AA2@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Kristian Larsson Message-ID: <57164239.4010603@spritelink.net> Date: Tue, 19 Apr 2016 16:35:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <9842_1461068224_571621C0_9842_459_1_9E32478DFA9976438E7A22F69B08FF921BB05AA2@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "'Zoric, Sladjana'" , 'Mikael Abrahamsson' , 'Ian Farrer' , "Martin.Adams@telekom.de" Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 14:35:44 -0000 On 19/04/16 14:17, stephane.litkowski@orange.com wrote: > Hi, > > We will not support all containers of the model but most of them. > > Now in term of model usage, two main usages : > - customer is using a portal to order the services, in this case > there is no need to advertise any deviation, as the REST or Netconf > client is also managed by the provider (client is the portal) > - Provider opens API to customers : > - customer is able to use directly L3SM using REST or Netconf : deviations need to be advertised. Right, I agree. I'm convinced the first model, with a pretty web UI will be the main interface but I'm hoping that the second model will gain some traction as well. With more FOSS tools around NC/RC/YANG it certainly could and why not eliminate one step of weakly modeled data. Often the customer has an internal structure for what they want, like addresses of all satellite offices, which they then convert to Excel and send to the provider who will convert it to something else. This model could remove those weakly modeled steps. > You will find attached a quick exercise (so I probably missed some) on what could be the features in the model tree. Features are identified between {}. > For some identities, we would need features : YANG 1.1 needed. > Just to start the discussion. Good start, I actually began looking at this but you were much faster. We have made almost the exact same choices :) What is authentication used for? Seems to be an empty container. kll > -----Original Message----- > From: Kristian Larsson [mailto:kristian@spritelink.net] > Sent: Tuesday, April 19, 2016 13:57 > To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; l3sm@ietf.org > Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sladjana' > Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model > > > > On 19/04/16 12:13, stephane.litkowski@orange.com wrote: >> The main issue with features is to define what should be a feature , >> and what is in the base and I'm afraid that we could fall in infinite >> discussions. > > Okay, sure, I can see how that is a non-trivial discussion but it's certainly not an impossible one. Instead you are advocating for the extreme opposite and not have any if-features at all, which results in a model so big that I will have to spend more time writing a deviation file for it than it would take me to write a new model. Okay, I'm exaggerating a bit but virtually all providers will define a deviation which I think means the model is fundamentally broken. Having deviations shouldn't be the normal state. > > Does Orange support all those PE-CE protocols? Do you do encryption? > Will you not have any deviations? > > Kind regards, > Kristian. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Wed Apr 20 00:42:27 2016 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 CED3612EC9D for ; Wed, 20 Apr 2016 00:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ejkLix_DLvu3 for ; Wed, 20 Apr 2016 00:42:23 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD6212EC9C for ; Wed, 20 Apr 2016 00:42:23 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 2377240470; Wed, 20 Apr 2016 09:42:22 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id DB6F820070; Wed, 20 Apr 2016 09:42:21 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0279.002; Wed, 20 Apr 2016 09:42:21 +0200 From: To: Kristian Larsson , "Ogaki, Kenichi" , 'Benoit Claise' , "l3sm@ietf.org" Thread-Topic: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHRmV8v5MUcs4/sNkyHy/KxHn2YC5+QbY6AgAB7CxD//+VsAIAARvLw///8CQCAACMiYIAACRKAgAE/KNA= Date: Wed, 20 Apr 2016 07:42:21 +0000 Message-ID: <7690_1461138142_571732DD_7690_114_1_9E32478DFA9976438E7A22F69B08FF921BB05D3C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5715E4F4.6090303@spritelink.net> <15600_1461060809_571604C9_15600_294_1_9E32478DFA9976438E7A22F69B08FF921BB059BF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <57161D24.6060300@spritelink.net> <9842_1461068224_571621C0_9842_459_1_9E32478DFA9976438E7A22F69B08FF921BB05AA2@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <57164239.4010603@spritelink.net> In-Reply-To: <57164239.4010603@spritelink.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "'Zoric, Sladjana'" , 'Mikael Abrahamsson' , 'Ian Farrer' , "Martin.Adams@telekom.de" Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 07:42:26 -0000 > What is authentication used for? Seems to be an empty container. We do not spend a lot of time on security part, so there is some adjustment= to do. The idea of authentication container was in case customer using an authenti= cated access type (PPP for example) and then could provide its own password. The container was for the moment here just for augmentation purpose. But we= can keep it, remove it, add more in, depending on feedback. Thx -----Original Message----- From: Kristian Larsson [mailto:kristian@spritelink.net]=20 Sent: Tuesday, April 19, 2016 16:36 To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; l3sm@iet= f.org Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sl= adjana' Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model On 19/04/16 14:17, stephane.litkowski@orange.com wrote: > Hi, > > We will not support all containers of the model but most of them. > > Now in term of model usage, two main usages : > - customer is using a portal to order the services, in this case there=20 > is no need to advertise any deviation, as the REST or Netconf client=20 > is also managed by the provider (client is the portal) > - Provider opens API to customers : > - customer is able to use directly L3SM using REST or Netconf : deviatio= ns need to be advertised. Right, I agree. I'm convinced the first model, with a pretty web UI will be= the main interface but I'm hoping that the second model will gain some tra= ction as well. With more FOSS tools around NC/RC/YANG it certainly could an= d why not eliminate one step of weakly modeled data.=20 Often the customer has an internal structure for what they want, like addre= sses of all satellite offices, which they then convert to Excel and send to= the provider who will convert it to something else. This model could remov= e those weakly modeled steps. > You will find attached a quick exercise (so I probably missed some) on wh= at could be the features in the model tree. Features are identified between= {}. > For some identities, we would need features : YANG 1.1 needed. > Just to start the discussion. Good start, I actually began looking at this but you were much faster.=20 We have made almost the exact same choices :) What is authentication used for? Seems to be an empty container. kll > -----Original Message----- > From: Kristian Larsson [mailto:kristian@spritelink.net] > Sent: Tuesday, April 19, 2016 13:57 > To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise';=20 > l3sm@ietf.org > Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, = Sladjana' > Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model > > > > On 19/04/16 12:13, stephane.litkowski@orange.com wrote: >> The main issue with features is to define what should be a feature ,=20 >> and what is in the base and I'm afraid that we could fall in infinite=20 >> discussions. > > Okay, sure, I can see how that is a non-trivial discussion but it's certa= inly not an impossible one. Instead you are advocating for the extreme oppo= site and not have any if-features at all, which results in a model so big t= hat I will have to spend more time writing a deviation file for it than it = would take me to write a new model. Okay, I'm exaggerating a bit but virtua= lly all providers will define a deviation which I think means the model is = fundamentally broken. Having deviations shouldn't be the normal state. > > Does Orange support all those PE-CE protocols? Do you do encryption? > Will you not have any deviations? > > Kind regards, > Kristian. > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > ___________________________________________________________________________= ______________________________________________ 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 Apr 20 06:18:12 2016 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 C087F12D6E2 for ; Wed, 20 Apr 2016 06:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 MJzKVUoqeyQO for ; Wed, 20 Apr 2016 06:18:07 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F31312D657 for ; Wed, 20 Apr 2016 06:18:06 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3KDI4su025155; Wed, 20 Apr 2016 14:18:04 +0100 Received: from 950129200 ([193.174.94.27]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3KDI3ls025149 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2016 14:18:04 +0100 From: "Adrian Farrel" To: , "'Kristian Larsson'" References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5715E4F4.6090303@spritelink.net> <15600_1461060809_571604C9_15600_294_1_9E32478DFA9976438E7A22F69B08FF921BB059BF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <57161D24.6060300@spritelink.net> <9842_1461068224_571621C0_9842_459_1_9E32478DFA9976438E7A22F69B08FF921BB05AA2@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <57164239.4010603@spritelink.net> <7690_1461138142_571732DD_7690_114_1_9E32478DFA9976438E7A22F69B08FF921BB05D3C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <7690_1461138142_571732DD_7690_114_1_9E32478DFA9976438E7A22F69B08FF921BB05D3C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Date: Wed, 20 Apr 2016 14:18:05 +0100 Message-ID: <03a101d19b07$137cd700$3a768500$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJQCPqd5x/Xo3VRTakEDozTpZ+zRwGdNa0lArACIo8CbUDnRAF6MXBQAoswUzYB2V+WFgF52Do6AUBZlqmeG1+SYA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22272.006 X-TM-AS-Result: No--34.627-10.0-31-10 X-imss-scan-details: No--34.627-10.0-31-10 X-TMASE-MatchedRID: hwsFDxVJcFlFXAohF8vNJqOONuzwygtG0vlakDvxh7wZ7erS+vApYz0o 1daYAEUFYoHXhXM8VVlIV3UhxtN0o4thqq74C5FqsaPcs3T4TL23dp6DuD+6wCIWzbRXGr/CapO lRLNHX8VxbMFzSdDaNKpAYgTOPJkm+VdtpE9/9fYaJIrAslQnsTUb/dhGoRHB0mAM2eipqlqJmk H7KsdVwJydXMjMB+a6qNscV9AN9zVxzwb0rKc34yVypP66BP0QMVx/3ZYby79sLh/5lHek3ExwY YUVwXgLUNobangs9AMShXqIw/6/k2QkgVelQi41pvwZ9GmdwDMpWss5kPUFdIXPicOCzLXARpcT EuutBQDdJqQNSoXNjAc6nr2vlQv/w0HD01v3jvoAsHFAeQm1at2wkjuv55PO6i5zlFx/UHSmEs1 TU8dOOnaVk589nXLJpwTEgW5td+2992PRM24ntnvTOl+0F0tEW3Tqgx/NSkr3Ru3JrjJxKPcgZS +tipLVvG2nbFCBoOKhkUmq6t7Gx++Qm7Tg9jG3fKmN9+B2Aw+7nrAU9KQxUWecrqZc3vabaoo0s tspgTEqvQsnk8WAgrk+AbNW2oIsKIB5A7IqyvFCknpRCwLDeavd3WuZF0KAVxk27EKh25KsqnEk U6FrjFslnVEKNJtDyzzjMEiASC0OwLYqF/p9l7rbxxduc6FPkk5xcxBziMER34ro7k23nfNvmSa CnjTlt+odoSua73aRk6XtYogiarQ/aqQZTRfKL+25vAeQJJf3IRre2/Nqdhd65AKojGV5vECLuM +h4RB+3BndfXUhXQ== Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 13:18:11 -0000 IMHO the augmentation mechanism (empty container) is the right approach because the options are very varied, customers will have very specific requirements, and different operators will offer different services (but I am not an operator!). Furthermore, it seems likely (to me) that the security augmentations that are developed will be common across a number of services. That speaks in favour of putting them in a separate (not L3SM-specific) model that can be pointed to from this model. Adrian > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of > stephane.litkowski@orange.com > Sent: 20 April 2016 08:42 > To: Kristian Larsson; Ogaki, Kenichi; 'Benoit Claise'; l3sm@ietf.org > Cc: 'Zoric, Sladjana'; 'Mikael Abrahamsson'; 'Ian Farrer'; > Martin.Adams@telekom.de > Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model > > > What is authentication used for? Seems to be an empty container. > > We do not spend a lot of time on security part, so there is some adjustment to > do. > The idea of authentication container was in case customer using an authenticated > access type (PPP for example) and then could provide its own password. > The container was for the moment here just for augmentation purpose. But we > can keep it, remove it, add more in, depending on feedback. > > Thx > > > -----Original Message----- > From: Kristian Larsson [mailto:kristian@spritelink.net] > Sent: Tuesday, April 19, 2016 16:36 > To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; l3sm@ietf.org > Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, > Sladjana' > Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model > > > > On 19/04/16 14:17, stephane.litkowski@orange.com wrote: > > Hi, > > > > We will not support all containers of the model but most of them. > > > > Now in term of model usage, two main usages : > > - customer is using a portal to order the services, in this case there > > is no need to advertise any deviation, as the REST or Netconf client > > is also managed by the provider (client is the portal) > > - Provider opens API to customers : > > - customer is able to use directly L3SM using REST or Netconf : deviations > need to be advertised. > > Right, I agree. I'm convinced the first model, with a pretty web UI will be the main > interface but I'm hoping that the second model will gain some traction as well. > With more FOSS tools around NC/RC/YANG it certainly could and why not > eliminate one step of weakly modeled data. > Often the customer has an internal structure for what they want, like addresses > of all satellite offices, which they then convert to Excel and send to the provider > who will convert it to something else. This model could remove those weakly > modeled steps. > > > > You will find attached a quick exercise (so I probably missed some) on what > could be the features in the model tree. Features are identified between {}. > > For some identities, we would need features : YANG 1.1 needed. > > Just to start the discussion. > > Good start, I actually began looking at this but you were much faster. > We have made almost the exact same choices :) > > What is authentication used for? Seems to be an empty container. > > kll > > > > -----Original Message----- > > From: Kristian Larsson [mailto:kristian@spritelink.net] > > Sent: Tuesday, April 19, 2016 13:57 > > To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; > > l3sm@ietf.org > > Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, > Sladjana' > > Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model > > > > > > > > On 19/04/16 12:13, stephane.litkowski@orange.com wrote: > >> The main issue with features is to define what should be a feature , > >> and what is in the base and I'm afraid that we could fall in infinite > >> discussions. > > > > Okay, sure, I can see how that is a non-trivial discussion but it's certainly not an > impossible one. Instead you are advocating for the extreme opposite and not > have any if-features at all, which results in a model so big that I will have to spend > more time writing a deviation file for it than it would take me to write a new > model. Okay, I'm exaggerating a bit but virtually all providers will define a > deviation which I think means the model is fundamentally broken. Having > deviations shouldn't be the normal state. > > > > Does Orange support all those PE-CE protocols? Do you do encryption? > > Will you not have any deviations? > > > > Kind regards, > > Kristian. > > > > > ______________________________________________________________ > ________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces > jointes. Les messages electroniques etant susceptibles d'alteration, Orange > decline toute responsabilite si ce message a ete altere, deforme ou falsifie. > Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete this > message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > > > ______________________________________________________________ > ___________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm From nobody Wed Apr 20 09:09:17 2016 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 3CA8112D777 for ; Wed, 20 Apr 2016 09:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 SGAeJVwZbL6j for ; Wed, 20 Apr 2016 09:09:12 -0700 (PDT) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DD612D71E for ; Wed, 20 Apr 2016 09:09:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id EAB12261846 for ; Wed, 20 Apr 2016 18:09:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWxJXlTRTMKt for ; Wed, 20 Apr 2016 18:09:08 +0200 (CEST) Received: from Kristians-MacBook-Pro.local (h-161-130.a515.priv.bahnhof.se [155.4.161.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 1D33626180E for ; Wed, 20 Apr 2016 18:09:08 +0200 (CEST) To: l3sm@ietf.org References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5715E4F4.6090303@spritelink.net> <15600_1461060809_571604C9_15600_294_1_9E32478DFA9976438E7A22F69B08FF921BB059BF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <57161D24.6060300@spritelink.net> <9842_1461068224_571621C0_9842_459_1_9E32478DFA9976438E7A22F69B08FF921BB05AA2@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <57164239.4010603@spritelink.net> <7690_1461138142_571732DD_7690_114_1_9E32478DFA9976438E7A22F69B08FF921BB05D3C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Kristian Larsson Message-ID: <5717A9A3.3000609@spritelink.net> Date: Wed, 20 Apr 2016 18:09:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <7690_1461138142_571732DD_7690_114_1_9E32478DFA9976438E7A22F69B08FF921BB05D3C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 16:09:15 -0000 If the authentication container is purely for augmentation I don't think we need a "security" if-feature on the security container, instead I would opt for an "encryption" if-feature on the encryption container. If someone supports authentication then it will be augmented by another model and the lack of such model is a clear indicator that no authentication is supported. As an native v6 only network I would like to see an if-feature for ipv4 :) kll On 20/04/16 09:42, stephane.litkowski@orange.com wrote: >> What is authentication used for? Seems to be an empty container. > > We do not spend a lot of time on security part, so there is some adjustment to do. > The idea of authentication container was in case customer using an authenticated access type (PPP for example) and then could provide its own password. > The container was for the moment here just for augmentation purpose. But we can keep it, remove it, add more in, depending on feedback. > > Thx > > > -----Original Message----- > From: Kristian Larsson [mailto:kristian@spritelink.net] > Sent: Tuesday, April 19, 2016 16:36 > To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; l3sm@ietf.org > Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sladjana' > Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model > > > > On 19/04/16 14:17, stephane.litkowski@orange.com wrote: >> Hi, >> >> We will not support all containers of the model but most of them. >> >> Now in term of model usage, two main usages : >> - customer is using a portal to order the services, in this case there >> is no need to advertise any deviation, as the REST or Netconf client >> is also managed by the provider (client is the portal) >> - Provider opens API to customers : >> - customer is able to use directly L3SM using REST or Netconf : deviations need to be advertised. > > Right, I agree. I'm convinced the first model, with a pretty web UI will be the main interface but I'm hoping that the second model will gain some traction as well. With more FOSS tools around NC/RC/YANG it certainly could and why not eliminate one step of weakly modeled data. > Often the customer has an internal structure for what they want, like addresses of all satellite offices, which they then convert to Excel and send to the provider who will convert it to something else. This model could remove those weakly modeled steps. > > >> You will find attached a quick exercise (so I probably missed some) on what could be the features in the model tree. Features are identified between {}. >> For some identities, we would need features : YANG 1.1 needed. >> Just to start the discussion. > > Good start, I actually began looking at this but you were much faster. > We have made almost the exact same choices :) > > What is authentication used for? Seems to be an empty container. > > kll > > >> -----Original Message----- >> From: Kristian Larsson [mailto:kristian@spritelink.net] >> Sent: Tuesday, April 19, 2016 13:57 >> To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; >> l3sm@ietf.org >> Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sladjana' >> Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model >> >> >> >> On 19/04/16 12:13, stephane.litkowski@orange.com wrote: >>> The main issue with features is to define what should be a feature , >>> and what is in the base and I'm afraid that we could fall in infinite >>> discussions. >> >> Okay, sure, I can see how that is a non-trivial discussion but it's certainly not an impossible one. Instead you are advocating for the extreme opposite and not have any if-features at all, which results in a model so big that I will have to spend more time writing a deviation file for it than it would take me to write a new model. Okay, I'm exaggerating a bit but virtually all providers will define a deviation which I think means the model is fundamentally broken. Having deviations shouldn't be the normal state. >> >> Does Orange support all those PE-CE protocols? Do you do encryption? >> Will you not have any deviations? >> >> Kind regards, >> Kristian. >> >> ______________________________________________________________________ >> ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm > From nobody Wed Apr 20 09:15:04 2016 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 4EAE312DFF4 for ; Wed, 20 Apr 2016 09:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 Tgup_6-j0fLf for ; Wed, 20 Apr 2016 09:15:00 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295F912E0D1 for ; Wed, 20 Apr 2016 09:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17410; q=dns/txt; s=iport; t=1461168900; x=1462378500; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=77mD+t6QWqPukTBPb18S+R/WHiim0IRDZKNR4i7LHGE=; b=UykV+QYeto/bASexowVi0lNGu2bwIbRtEaFlj2vrEfxwOTfhLwnBeQTc iYCV3YpAsnSlcFNicoEHMJvCogHHEXt1OaGo/bvdlg9q/0jC1D0ttipMh RKqUPQs6Gi15PQ0upVZLtEiDjLOqKdyicTzF8C/lsymkezL6znVW8EhCv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWCgCsqRdX/xbLJq1ehDlPu2yIIgEBA?= =?us-ascii?q?QEBAWYnhGsVLws8AgUhAhECWQYCAQGIJZ1vj12ROHyFJYhlgyWCVgWNU4o8gS6?= =?us-ascii?q?GfkSFJIk5hVePLWKCBAUVgUs7MIcLgTwBAQE?= X-IronPort-AV: E=Sophos;i="5.24,510,1454976000"; d="scan'208";a="637092138" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2016 16:14:57 +0000 Received: from [10.63.23.138] (dhcp-ensft1-uk-vla370-10-63-23-138.cisco.com [10.63.23.138]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3KGEvSk021018 for ; Wed, 20 Apr 2016 16:14:57 GMT To: l3sm@ietf.org From: David Ball Message-ID: <5717AB01.90908@cisco.com> Date: Wed, 20 Apr 2016 17:14:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [L3sm] Feedback on L3SM draft X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 16:15:03 -0000 Hi, I would like to introduce myself as the editor of the MEF IP Service Attributes project. In the MEF, we have been considering the latest L3SM draft (draft-ietf-l3sm-l3vpn-service-model-05) during the last quarter, and in that context and as requested in your recent liaison, I would like to provide some questions and comments. Note that this is my personal feedback, not that of MEF. Some of my comments are for information only (I have marked these with "(I)"). Many others are questions to ensure I have understood the model correctly - in these cases, as well as answering my questions, it may be useful to add additional explanation to the draft to help other readers, even if no changes are needed to the yang module itself. * (I) Abstract: It is stated here, and again in Sn 4, that the intent of this model is that it can be instantiated by a management system in the SP, i.e. it contains all of the info needed to allow the management system to configure the SP's network elements so as to correctly provision the service. Note that this is similar, but not identical, to the focus of the MEF work, which is to define the set of attributes that must be contractually (or otherwise) agreed between the SP and the subscriber. * Sn 5: The "bearer" is described as refering to the physical properties of the attachment, as opposed to the protocol oriented properties. Are L2 aspects considered to be physical properties or protocol oriented properties? For instance, suppose the attachment is via a VLAN over an Ethernet LAG containing 2 physical Ethernet interfaces: is the bearer the VLAN, the LAG, or the physical interfaces? * Sn 5.1.1.4: Could you add an example of when hub-and-spoke-disjoint is used? Is it the same as having 2 hub-and-spoke VPNs where each hub site belongs to a different VPN and all the spoke sites belong to both VPNs? * Sn 5.1.2: It is unclear to me how a Cloud identifier (e.g. "Cloud1") is associated with a particular cloud service (say, Amazon Web Services). Is there an assumption that the management system that is instantiating this yang model has auxilliary knowledge about the cloud service that each Cloud ID is actually associated with (configured by some means outside the scope of this model)? For the subscriber to order a cloud service, they also need to know what actual service each Cloud ID is associated with - is that also assumed to be known by means outside this model? * Sn 5.1.4: I was a bit confused by the description of extranet. If VPN A lists VPN B as an extranet, then the text states that the relationship must be bi-directional. However, the site-role leaf means that it is not necessarily symmetric. My interpretation is that if VPN B has hub-and-spoke (or hub-and-spoke-disjoint) topology, then sites in A might only be able to access certain sites in B (depending on the specified role); however, those sites in B would always be able to access all sites in A. Is this interpretation correct? Presumably the requirements in Sn 5.2.1 are intended to also apply to the site-role leaf for the extranet, in respect of the topology of the VPN listed as the extranet? It would be good to state that explicitly. * Sn 5.2.2.1.2: In the case of a site connected to multiple VPNs, how is traffic received from the site mapped to the right VPN? It is important to know which VPN the traffic maps to, not only to ensure it is sent to the right destination, but also because different VPNs might have different bandwidth or performance attributes. As described later on (Sn 5.2.2.2), a VPN policy can be used with a filter that limits the LANs that belong to each VPN (which implies that a packet can be mapped to a VPN based on its source address); however, I don't think there is a requirement that filters are used to ensure that each possible LAN only belongs to a single VPN. Is the intention that filters are used to partition the LANs, or can a packet with a given source address potentially belong to multiple VPNs? If so, is the implication that the destination address is looked up in each VPN? Is it possible that a route to the destination exists in multiple VPNs? How is the order of the VPNs in which to perform the lookups determined in that case? For instance, looking at the first example in Sn 5.2.2.2.2 (VPN policy), when a packet is received from VPN3_Site2 at PE6, how does PE6 determine whether to handle the packet as part of VPN2 or VPN3? * Sn 5.2.2.1.3: Both from the perspective of what the management system needs to know to provision the SPs network, and from what needs to be agreed between the SP an the customer, this "Sub VPN attachment" case seems to be indistinguishable from treating it as separate sites. The text says: "It is similar than having separate sites instead that the customer wants to share some physical components while keeping strong isolation". However, from a service definition perspective, whether two separate sites happen to share the same physical infrastructure is immaterial, and in fact this could (or should) be invisible to the SP. I don't understand what additional value this "Sub VPN attachment" case provides. * Sn 5.2.3.1: In the case of a service-provider defined template, how would the customer be aware of what the template contains? Is it assumed to be made available by some mechanism outside the scope of this yang module? * Sn 5.2.4: I think there is a conflict between the definitions in section 2 and the values described in this section. According to section 2, the "CE" is on the customer side of the SP-customer boundary, which I take to mean it is owned and managed by the customer. Given this definition, it would seem that a "provider-managed" service is impossible - if the provider manages a CPE device that is not VPN aware, then that is not the "CE" according to the definitions in section 2, it is the "PE". The definitions in section 2 don't seem to align with what is normally understood by "PE" and "CE" in this case. Furthermore, section 3 limits the scope of the model to BGP PE-Based VPNs, so this case - where the "PE" (per section 2) is a CPE that is not VPN aware - is out of scope per Sn 3. I don't think that is the intent; this situation is clearly intended to be in scope (especially as this is exactly the case described by the example in Sn 6); so I think either the definitions in Sn 2 or the scope statement in Sn 3 (or both) need to be modified. Note that this impacts several other parts of the document: e.g. 5.2.5 refers to a "CE-customer" boundary, 5.2.7.2 refers to a "CE to LAN connection", etc - neither of which makes sense given the current definitions in section 2. On the other hand, changing the definitions may also have other impacts, e.g. site diversity, acccess diversity, traffic protection, etc are described in terms of the CE-PE links, but for provider-managed sites perhaps they are intended to apply to the CE-customer links (or perhaps not)? * Sn 5.2.4: Assuming the above problem is fixed, it is not clear what "comanaged" means or how that affects the rest of the model. Where is the demarcation between the SP and the subscriber in this case? Also, in the case of provider-managed, wouldn't the management address (of the CE??) be internal to the SP (i.e., it could be allocated in a similar way to RTs and RDs)? It's not something the customer needs to be aware of, right? * (I) Sn 5.2.5: For information, MEF members indicated that several other protocols are in use that would need to be added to this list (in particular, ISIS and EIGRP). * Sn 5.2.5.2: In this case, is the implication that the customer uses a default route towards the SP? How does the customer determine the gateway address to use? (Same question also applies in the VRRP and static cases). * Sn 5.2.5.2: This seems to be describing a case where the SP-customer link could be a multipoint link; for example, where the SP provides a WiFi access point to a residential subscriber. Is that right? It seems like there would need to be several other restrictions in this case - for example, the connection addressing would need to be DHCP or SLAAC (since the static option can only be used to provide a single address for the customer), and this likely only applies to provider-managed sites. Some P2P aspects like BFD and encryption would need to be disabled. * (I) Sn 5.2.5.3: The use of VRRP should be invisible to the customer; so this is an example of something that does not need to be agreed between the SP and the customer, but which the management system in the SP needs to provision in the PEs. * Sn 5.2.6.1: The QoS profile is described as the "outgoing QoS profile to be applied" - if I understand that correctly, it means the QoS profile only specifies egress policing, it does not specify any ingress policing - is that correct? * Sn 5.2.6.1.2: In the case of standard profiles, how does the customer know what they are? Is that assumed to be done by means outside the scope of this yang module? Also, the priority relates to strict priority queuing - is strict priority queuing required when this yang module is used, or can other mechanisms also be used? * Sn 5.2.6.1.2: The rate-limit is described as "a percentage of the global service bandwidth" - is the "global service bandwidth" the value specified in the "svc-output-bandwidth" leaf? Similarly, the guaranteed-bw-percent is "expressed as a percentage", but it doesn't say what it is a percentage of. Is this also a percentage of the value in the "svc-output-bandwidth" leaf? * Sn 5.2.7: Some parameters can be configured at the site level or at the network-access level; but it seems like certain parameters only make sense at one or the other; for example, it is unlikely you would want different routing protocols on different network access links, but you might want to assign different metrics to different links. How is this handled? * Sn 5.2.7.2.1: In the case of DHCP (or SLAAC), is the assumption that it is used to provide (at least) the customer address, subnet mask and default gateway address? Also is there an assumption that a static-address is used in the case where the routing protocol is BGP? * Sn 5.2.8: I found this description unclear - is the intent that this information is all internal to the SP, and used to give information to the management system; or is it intended to be a way for the customer to provide hints to the SP, which the SP may choose to ignore? * Sn 5.2.8: My reading of this paragraph is that the SP can decide how to connect each site based on any constraint, and that the ones listed here are optional and are to be treated as hints by the management system. However, some of the following subsections have hard requirements (MUSTs). What is the intent here? * Sn 5.2.8.2: I am not sure how to interpret these requirements if the sites have more than one network-access link (to different PEs). Do they mean that two sites in the same site-group must have at least one network-access link to a different PE/PoP, or that the PEs/PoPs that network-access links connect to must be completely disjoint sets? Or do they only apply to sites with a single network-access link? If two sites both have two network-accesses, then even if they are connected to the same 2 PEs, a PE failure would not impact connectivity to them or between them. For example, is it allowed to have site A connected to PE 1 and PE 2, and site B connected to PE 2 and PE 3, if they both are set to PE diverse and are in the same site group? What if site B is connected to PE 1 and PE 2? Also, what is the required behaviour if some sites in the site-group are set to PE-diverse and some are set to PoP-diverse? * Sn 5.2.8.3: Similar question here: what is the expected behaviour if one access link is set to PE-diverse and one is set to PoP-diverse? Also is a "none" option needed, for when it's ok for both links to terminate at the same PE? * Sn 5.2.8.3: I think there is a problem with this way of specifying the availability behaviour based on access priorities. In the complex example in the last paragraph, it says that if A1 and A2 fail, the traffic will be load-shared on A3 and A4. However, if only A1 fails, the traffic would all be forced on to A2, right? This is unlikely to be desirable - probably what the customer wants is to always be load-sharing on 2 links, unless all of A1 - A4 fail (i.e., if only A1 fails, then load-share on A2 and A3). There doesn't seem to be a way to specify that using access priorities. Having said that, this may not be a problem in practice: the SPs in MEF all indicated that they never have more than 2 links to a given site. * Sn 5.2.8.3.1: If I understand correctly, the difference between traffic protection enabled and disabled would be in how quickly the SP can restore traffic towards a site if one of the network-access links fails - is that correct? I'm not sure how useful this is without putting some numbers in here - i.e. if the customer pays extra for a service with traffic protection enabled, what traffic restoration speed is the SP targeting or guaranteeing? Also, what is the expected behaviour if traffic protection is enabled on one network-access link but disabled on another? Shouldn't it be an attribute that applies to the site as a whole rather than to each network-access link separately? (I) For info: in MEF this would likely be covered by an SLS objective; it would be up to the SP to determine whether they needed to enable traffic protection or not in order to meet the SLS in the event of a link failure, rather than the customer requesting this explicitly. * Sn 5.3.1: In RFC 4364, this is called "Carrier's carrier" rather than "Carrier supporting Carrier" - I think the latter is Cisco's name for the same feature. It would be better to use the RFC4364 name in this draft. Also in the yang module, it would be clearer to call the leaf "carriers-carrier" or similar, rather than "mpls". * Sn 5.3.2: Some of these constraints are not clearly defined. I assume that the latency and jitter constraints specify the maximum latency and jitter, whereas the bandwidth is the minimum bandwidth? Do these constraints apply to all received packets for all traffic classes? I do not understand the site diversity constraint - how would a path between 2 sites cross any other sites? Does it mean "are not crossing the same P routers"? Or does it mean that the paths are physically diverse? (I) In MEF, I expect that all of these constraints would be covered by the SLS. * Sn 5.4: The text here mentions "if apply-template is done on service container of a site", and the example also shows a service container with an apply-template leaf - but in the yang module, there is no apply-template leaf in the service container. The yang only has apply-template for the site and for network-accesses. * Sn 6: As described in Sn 5.2.5, the routing protocol specified in the model applies to the SP-customer link; however, in the example described in this section, it is described as applying to the PE-CE link, even though the CE is provider-managed and so the SP-customer link is between the CE and the customer (e.g. it says "Routing protocols will also be configured on the PE, bgp will be used as requested in the service model.") In the provider-managed case, the routing protocol used between the CE and the PE would be internal to the provider and not specified in the model. * Sn 8: What are the svc-input-bandwidth and svc-output-bandwidth? I think the svc-output-bandwidth may be related to the QoS profile (see earlier comments), but what is the svc-input-bandwidth for? * Sn 8: If MPLS is enabled (i.e. the CsC case), does the svc-mtu value include the MPLS labels or just the IP packet? * Sn 8: Is there ever a case where the "list routing-protocol" can contain more than 2 entries (i.e., one for IPv4 and one for IPv6)? * Sn 8: For the ip-connection, how is the "subnet-only" case used? In this case, how are the SP's and the customer's addresses assigned and known? Also should the "subnet" choice apply only when the address-allocation-type is static (i.e., add a "when" statememt)? * Sn 8: The OAM parameters are not described in Sn 5 - is this an omission? In the case of a holdtime specified with a profile, how would the customer know what the contents of the profile is? Thanks, David -- David Ball From nobody Wed Apr 20 23:00:48 2016 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 EABD112DFA2 for ; Wed, 20 Apr 2016 23:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 FI1W3iR21PZ1 for ; Wed, 20 Apr 2016 23:00:44 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFFD12DE66 for ; Wed, 20 Apr 2016 23:00:44 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 9D539C03BC; Thu, 21 Apr 2016 08:00:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 757001C006C; Thu, 21 Apr 2016 08:00:42 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0279.002; Thu, 21 Apr 2016 08:00:42 +0200 From: To: Kristian Larsson , "l3sm@ietf.org" Thread-Topic: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHRmV8v5MUcs4/sNkyHy/KxHn2YC5+QbY6AgAB7CxD//+VsAIAARvLw///8CQCAACMiYIAACRKAgAE/KNCAAG1NgIABCbEg Date: Thu, 21 Apr 2016 06:00:41 +0000 Message-ID: <32383_1461218442_57186C8A_32383_19457_1_9E32478DFA9976438E7A22F69B08FF921BB07C8B@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <5714BA5A.2030701@cisco.com> <010a01d199e0$ea800ec0$bf802c40$@kddi.com> <28630_1461051228_5715DF5C_28630_192_1_9E32478DFA9976438E7A22F69B08FF921BB05850@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5715E4F4.6090303@spritelink.net> <15600_1461060809_571604C9_15600_294_1_9E32478DFA9976438E7A22F69B08FF921BB059BF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <57161D24.6060300@spritelink.net> <9842_1461068224_571621C0_9842_459_1_9E32478DFA9976438E7A22F69B08FF921BB05AA2@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <57164239.4010603@spritelink.net> <7690_1461138142_571732DD_7690_114_1_9E32478DFA9976438E7A22F69B08FF921BB05D3C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5717A9A3.3000609@spritelink.net> In-Reply-To: <5717A9A3.3000609@spritelink.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 06:00:47 -0000 As an native v6 only network I would like to see an if-feature for ipv4 :) [SLI] LOL, agree , that looks acceptable ;) -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Kristian Larsson Sent: Wednesday, April 20, 2016 18:09 To: l3sm@ietf.org Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model If the authentication container is purely for augmentation I don't think we= need a "security" if-feature on the security container, instead I would op= t for an "encryption" if-feature on the encryption container. If someone su= pports authentication then it will be augmented by another model and the la= ck of such model is a clear indicator that no authentication is supported. As an native v6 only network I would like to see an if-feature for ipv4 :) kll On 20/04/16 09:42, stephane.litkowski@orange.com wrote: >> What is authentication used for? Seems to be an empty container. > > We do not spend a lot of time on security part, so there is some adjustme= nt to do. > The idea of authentication container was in case customer using an authen= ticated access type (PPP for example) and then could provide its own passwo= rd. > The container was for the moment here just for augmentation purpose. But = we can keep it, remove it, add more in, depending on feedback. > > Thx > > > -----Original Message----- > From: Kristian Larsson [mailto:kristian@spritelink.net] > Sent: Tuesday, April 19, 2016 16:36 > To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise';=20 > l3sm@ietf.org > Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, = Sladjana' > Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model > > > > On 19/04/16 14:17, stephane.litkowski@orange.com wrote: >> Hi, >> >> We will not support all containers of the model but most of them. >> >> Now in term of model usage, two main usages : >> - customer is using a portal to order the services, in this case=20 >> there is no need to advertise any deviation, as the REST or Netconf=20 >> client is also managed by the provider (client is the portal) >> - Provider opens API to customers : >> - customer is able to use directly L3SM using REST or Netconf : deviati= ons need to be advertised. > > Right, I agree. I'm convinced the first model, with a pretty web UI will = be the main interface but I'm hoping that the second model will gain some t= raction as well. With more FOSS tools around NC/RC/YANG it certainly could = and why not eliminate one step of weakly modeled data. > Often the customer has an internal structure for what they want, like add= resses of all satellite offices, which they then convert to Excel and send = to the provider who will convert it to something else. This model could rem= ove those weakly modeled steps. > > >> You will find attached a quick exercise (so I probably missed some) on w= hat could be the features in the model tree. Features are identified betwee= n {}. >> For some identities, we would need features : YANG 1.1 needed. >> Just to start the discussion. > > Good start, I actually began looking at this but you were much faster. > We have made almost the exact same choices :) > > What is authentication used for? Seems to be an empty container. > > kll > > >> -----Original Message----- >> From: Kristian Larsson [mailto:kristian@spritelink.net] >> Sent: Tuesday, April 19, 2016 13:57 >> To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise';=20 >> l3sm@ietf.org >> Cc: Martin.Adams@telekom.de; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric,= Sladjana' >> Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model >> >> >> >> On 19/04/16 12:13, stephane.litkowski@orange.com wrote: >>> The main issue with features is to define what should be a feature ,=20 >>> and what is in the base and I'm afraid that we could fall in=20 >>> infinite discussions. >> >> Okay, sure, I can see how that is a non-trivial discussion but it's cert= ainly not an impossible one. Instead you are advocating for the extreme opp= osite and not have any if-features at all, which results in a model so big = that I will have to spend more time writing a deviation file for it than it= would take me to write a new model. Okay, I'm exaggerating a bit but virtu= ally all providers will define a deviation which I think means the model is= fundamentally broken. Having deviations shouldn't be the normal state. >> >> Does Orange support all those PE-CE protocols? Do you do encryption? >> Will you not have any deviations? >> >> Kind regards, >> Kristian. >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm > _______________________________________________ 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 Thu Apr 21 00:56:17 2016 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 4B9B912EA5F for ; Thu, 21 Apr 2016 00:56:15 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Red0BVHPrMsF for ; Thu, 21 Apr 2016 00:56:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E9A12EA54 for ; Thu, 21 Apr 2016 00:56:09 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id AAF362643AB; Thu, 21 Apr 2016 09:56:07 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8572F35C04E; Thu, 21 Apr 2016 09:56:07 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0279.002; Thu, 21 Apr 2016 09:56:07 +0200 From: To: David Ball , "l3sm@ietf.org" Thread-Topic: [L3sm] Feedback on L3SM draft Thread-Index: AQHRmx/OuCnEXvw7QESYANDcSs89x5+T8EpQ Date: Thu, 21 Apr 2016 07:56:07 +0000 Message-ID: <9485_1461225367_57188797_9485_1886_9_9E32478DFA9976438E7A22F69B08FF921BB091AF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <5717AB01.90908@cisco.com> In-Reply-To: <5717AB01.90908@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.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.14.165416 Archived-At: Subject: Re: [L3sm] Feedback on L3SM draft X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 07:56:16 -0000 Hi, Thanks for the comment, please find inline comments. -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball Sent: Wednesday, April 20, 2016 18:15 To: l3sm@ietf.org Subject: [L3sm] Feedback on L3SM draft Hi, I would like to introduce myself as the editor of the MEF IP Service Attrib= utes project. In the MEF, we have been considering the latest L3SM draft (= draft-ietf-l3sm-l3vpn-service-model-05) during the last quarter, and in tha= t context and as requested in your recent liaison, I would like to provide = some questions and comments. Note that this is my personal feedback, not t= hat of MEF. Some of my comments are for information only (I have marked these with "(I)= "). Many others are questions to ensure I have understood the model correc= tly - in these cases, as well as answering my questions, it may be useful t= o add additional explanation to the draft to help other readers, even if no= changes are needed to the yang module itself. * (I) Abstract: It is stated here, and again in Sn 4, that the intent of this model is that it can be instantiated by a management system in the SP, i.e. it contains all of the info needed to allow the management system to configure the SP's network elements so as to correctly provision the service. Note that this is similar, but not identical, to the focus of the MEF work, which is to define the set of attributes that must be contractually (or otherwise) agreed between the SP and the subscriber. * Sn 5: The "bearer" is described as refering to the physical properties of the attachment, as opposed to the protocol oriented properties. Are L2 aspects considered to be physical properties or protocol oriented properties? For instance, suppose the attachment is via a VLAN over an Ethernet LAG containing 2 physical Ethernet interfaces: is the bearer the VLAN, the LAG, or the physical interfaces? [SLI] The goal of the model is to focus on Layer 3. Bearer is just a refere= nce to everything under layer 3, so as your example, VLAN is considered as = bearer. One "issue" we have to deal with in L3SM, is that we cannot manage all the = access types as it's really different from one provider to the other and th= ere are plenty of accesses. Moreover it's not really a L3VPN topic. So two cases : - the customer orders an access separately of the L3VPN site, in this case,= the bearer reference needs to be attached, so the customer provides a refe= rence to an existing access to the provider. - the customer orders an access at the same time of the L3VPN site. The pro= vider will need to provide an access type that fills the customer requireme= nt in term of diversity, bandwidth, services ... The first option is here just in case the customer does not want to use an = automated access election procedure but wants a really specific access type= . This makes me thing that an "always-on" boolean may be necessary for some= backup scenario ... * Sn 5.1.1.4: Could you add an example of when hub-and-spoke-disjoint is used? Is it the same as having 2 hub-and-spoke VPNs where each hub site belongs to a different VPN and all the spoke sites belong to both VPNs? [SLI] Yes this is similar to the case you mention. * Sn 5.1.2: It is unclear to me how a Cloud identifier (e.g. "Cloud1") is associated with a particular cloud service (say, Amazon Web Services). Is there an assumption that the management system that is instantiating this yang model has auxilliary knowledge about the cloud service that each Cloud ID is actually associated with (configured by some means outside the scope of this model)? [SLI] That's the point. OSS needs some knowledge about what is Cloud1 and C= loud2, this can be hardcoded or retrieved from another system. The same hap= pens with standard QoS or encryption profiles ... For the subscriber to order a cloud service, they also need to know what actual service each Cloud ID is associated with - is that also assumed to be known by means outside this model? [SLI] Provider can communicate to customer the list of CloudIDs to be used.= Is that an issue ? We cannot really define a list of clouds here ... I think we need to keep i= t flexible. * Sn 5.1.4: I was a bit confused by the description of extranet. If VPN A lists VPN B as an extranet, then the text states that the relationship must be bi-directional. However, the site-role leaf means that it is not necessarily symmetric. My interpretation is that if VPN B has hub-and-spoke (or hub-and-spoke-disjoint) topology, then sites in A might only be able to access certain sites in B (depending on the specified role); however, those sites in B would always be able to access all sites in A. Is this interpretation correct? [SLI] Bi-directional does not mean symmetric here. It just mean that if you= configure extranet in VPN A to access to VPN B, you don't need to configur= e the reverse (VPN B accessing to VPN A). Now in term of real communication= s between sites, the VPN topology will dictate it as you mentioned. Presumably the requirements in Sn 5.2.1 are intended to also apply to the site-role leaf for the extranet, in respect of the topology of the VPN listed as the extranet? It would be good to state that explicitly. [SLI] Yes for sure. Will enhance text in future revision. * Sn 5.2.2.1.2: In the case of a site connected to multiple VPNs, how is traffic received from the site mapped to the right VPN? It is important to know which VPN the traffic maps to, not only to ensure it is sent to the right destination, but also because different VPNs might have different bandwidth or performance attributes. [SLI] No, attributes you are referring to are sites attributes, not VPN att= ributes. In multiVPN scenario, the same logical access is used to access to all VPNs= : for instance, bandwidth is shared. As described later on (Sn 5.2.2.2), a VPN policy can be used with a filter that limits the LANs that belong to each VPN (which implies that a packet can be mapped to a VPN based on its source address); [SLI] Yes and no, from a service point of view, this can be seen as source= based VPN association. Now, in reality (device implementation), it's still a destination based as= sociation, each LAN will be advertised with a different RT, so the return t= raffic is using a different VPN.=20 however, I don't think there is a requirement that filters are used to ensure that each possible LAN only belongs to a single VPN. Is the intention that filters are used to partition the LANs, or can a packet with a given source address potentially belong to multiple VPNs? [SLI] There is no limitation here, each LAN can belong to a single VPN, or = a LAN can belong to multiple VPNs, or just some ... For instance, one use c= ase (at least for us) is ToIP, where only Voice LANs need to be part of a c= ustomer Voice VPN, and the others are belonging to the regular customer IPV= PN. If so, is the implication that the destination address is looked up in each VPN? Is it possible that a route to the destination exists in multiple VPNs? How is the order of the VPNs in which to perform the lookups determined in that case? For instance, looking at the first example in Sn 5.2.2.2.2 (VPN policy), when a packet is received from VPN3_Site2 at PE6, how does PE6 determine whether to handle the packet as part of VPN2 or VPN3? [SLI] The IP destination is used. The destination IP can be part of VPN2 or= VPN3. * Sn 5.2.2.1.3: Both from the perspective of what the management system needs to know to provision the SPs network, and from what needs to be agreed between the SP an the customer, this "Sub VPN attachment" case seems to be indistinguishable from treating it as separate sites. The text says: "It is similar than having separate sites instead that the customer wants to share some physical components while keeping strong isolation". However, from a service definition perspective, whether two separate sites happen to share the same physical infrastructure is immaterial, and in fact this could (or should) be invisible to the SP. I don't understand what additional value this "Sub VPN attachment" case provides. [SLI] This is a discussion we already had about how to model SubVPN. Considering them as separate sites was evaluated but there was some need to= correlate sites that belongs the the same sub-VPN. This is particularly true when the= SP provides the access.=20 The SP needs to know that the IP sites must be built on the same access. * Sn 5.2.3.1: In the case of a service-provider defined template, how would the customer be aware of what the template contains? Is it assumed to be made available by some mechanism outside the scope of this yang module? [SLI] The idea to have customer to create template, not really the provider. * Sn 5.2.4: I think there is a conflict between the definitions in section 2 and the values described in this section. According to section 2, the "CE" is on the customer side of the SP-customer boundary, which I take to mean it is owned and managed by the customer. Given this definition, it would seem that a "provider-managed" service is impossible - if the provider manages a CPE device that is not VPN aware, then that is not the "CE" according to the definitions in section 2, it is the "PE". The definitions in section 2 don't seem to align with what is normally understood by "PE" and "CE" in this case. [SLI] Agree, my mistake, I will need to update definitions in Section 2. It was a bad copy/paste. Furthermore, section 3 limits the scope of the model to BGP PE-Based VPNs, so this case - where the "PE" (per section 2) is a CPE that is not VPN aware - is out of scope per Sn 3. [SLI] Not sure to catch the case you mention here .. I don't think that is the intent; this situation is clearly intended to be in scope (especially as this is exactly the case described by the example in Sn 6); so I think either the definitions in Sn 2 or the scope statement in Sn 3 (or both) need to be modified. Note that this impacts several other parts of the document: e.g. 5.2.5 refers to a "CE-customer" boundary, 5.2.7.2 refers to a "CE to LAN connection", etc - neither of which makes sense given the current definitions in section 2. On the other hand, changing the definitions may also have other impacts, e.g. site diversity, acccess diversity, traffic protection, etc are described in terms of the CE-PE links, but for provider-managed sites perhaps they are intended to apply to the CE-customer links (or perhaps not)? [SLI] CE is located at customer premise whatever the management model. Site diversity ... always refers to CE-PE connection (customer site to prov= ider network). * Sn 5.2.4: Assuming the above problem is fixed, it is not clear what "comanaged" means or how that affects the rest of the model. Where is the demarcation between the SP and the subscriber in this case? Also, in the case of provider-managed, wouldn't the management address (of the CE??) be internal to the SP (i.e., it could be allocated in a similar way to RTs and RDs)? It's not something the customer needs to be aware of, right? [SLI]=20 co-managed means that it's provided and managed by the SP , but the custome= r can access it. Demarcation is the same as provider managed case. I will add more text to p= recise it. * (I) Sn 5.2.5: For information, MEF members indicated that several other protocols are in use that would need to be added to this list (in particular, ISIS and EIGRP). [SLI] IS-IS as PE-CE ?=20 EIGRP is not really a standard protocol, it can be added through augmentati= on I think, a bit like HSRP. * Sn 5.2.5.2: In this case, is the implication that the customer uses a default route towards the SP? How does the customer determine the gateway address to use? (Same question also applies in the VRRP and static cases). [SLI] Good point, the subnet-only option for static allocation of IP addres= ses causes an issue here. If customer uses "addresses" container, it allocates provider address so he= knows the gateway. With dynamic allocation, like DHCP, gateway can be learned. We can remove the subnet-only option. * Sn 5.2.5.2: This seems to be describing a case where the SP-customer link could be a multipoint link; for example, where the SP provides a WiFi access point to a residential subscriber. Is that right? [SLI] Why multipoint ? It seems like there would need to be several other restrictions in this case - for example, the connection addressing would need to be DHCP or SLAAC (since the static option can only be used to provide a single address for the customer), and this likely only applies to provider-managed sites. Some P2P aspects like BFD and encryption would need to be disabled. * (I) Sn 5.2.5.3: The use of VRRP should be invisible to the customer; so this is an example of something that does not need to be agreed between the SP and the customer, but which the management system in the SP needs to provision in the PEs. [SLI] VRRP case is a bit tricky. This is the case where customer has direct LAN connections multihomed to tw= o PEs, so there are two logical accesses. Now the customer wants only direct routing but with redundancy. I think we can deduce from routing protocol=3Ddirect + presence of the avai= lability container that we need to implement VRRP. Does it work for you ? * Sn 5.2.6.1: The QoS profile is described as the "outgoing QoS profile to be applied" - if I understand that correctly, it means the QoS profile only specifies egress policing, it does not specify any ingress policing - is that correct? [SLI] Yes, only egress policing. * Sn 5.2.6.1.2: In the case of standard profiles, how does the customer know what they are? Is that assumed to be done by means outside the scope of this yang module? [SLI] Yes communication needed between SP and customer. Also, the priority relates to strict priority queuing - is strict priority queuing required when this yang module is used, or can other mechanisms also be used? [SLI] The exact mechanism to be used does not really care here.=20 >From a service point of view, we provide multiple level of priorities, and = within each level, we can provide a guaranteed bandwidth. * Sn 5.2.6.1.2: The rate-limit is described as "a percentage of the global service bandwidth" - is the "global service bandwidth" the value specified in the "svc-output-bandwidth" leaf? Similarly, the guaranteed-bw-percent is "expressed as a percentage", but it doesn't say what it is a percentage of. Is this also a percentage of the value in the "svc-output-bandwidth" leaf? [SLI] Yes it's a percentage of svc-output-bandwidth or input-bandwidth (dep= ending if the access is symmetric in term of BW or not). I will add more text to precise it. * Sn 5.2.7: Some parameters can be configured at the site level or at the network-access level; but it seems like certain parameters only make sense at one or the other; for example, it is unlikely you would want different routing protocols on different network access links, but you might want to assign different metrics to different links. How is this handled? [SLI] Well, this was an old discussion also. It looks that there is some SP using different protocols in multihoming sce= narios (ex : BGP on one side, static on the other, or OSPF ...). That expla= in why we need routing protocol container at site network access level. * Sn 5.2.7.2.1: In the case of DHCP (or SLAAC), is the assumption that it is used to provide (at least) the customer address, subnet mask and default gateway address? Also is there an assumption that a static-address is used in the case where the routing protocol is BGP? [SLI] Yes, we can precise it. * Sn 5.2.8: I found this description unclear - is the intent that this information is all internal to the SP, and used to give information to the management system; or is it intended to be a way for the customer to provide hints to the SP, which the SP may choose to ignore? [SLI] That's the point. Service placement is up to the SP but customer can influence it especially = for the diversity purpose. In case the SP provides diversity service it needs to fill it and must not = ignore it.=20 * Sn 5.2.8: My reading of this paragraph is that the SP can decide how to connect each site based on any constraint, and that the ones listed here are optional and are to be treated as hints by the management system. However, some of the following subsections have hard requirements (MUSTs). What is the intent here? [SLI] Diversity constraint is a constraint that the SP cannot ignore. After that SP is free to place the service based on its own policy. * Sn 5.2.8.2: I am not sure how to interpret these requirements if the sites have more than one network-access link (to different PEs). Do they mean that two sites in the same site-group must have at least one network-access link to a different PE/PoP, or that the PEs/PoPs that network-access links connect to must be completely disjoint sets? [SLI] PEs/PoPs must be completely disjoint set. But I could agree that this= is strong. In case of multihoming, "pe-diverse" applies between site-network-accesses. Or do they only apply to sites with a single network-access link? [SLI] No, that should work with multihomed. If two sites both have two network-accesses, then even if they are connected to the same 2 PEs, a PE failure would not impact connectivity to them or between them. For example, is it allowed to have site A connected to PE 1 and PE 2, and site B connected to PE 2 and PE 3, if they both are set to PE diverse and are in the same site group? What if site B is connected to PE 1 and PE 2? [SLI] Customer does not require diversity in this case, because diversity i= s already provided by multihoming which is "pe-diverse" by default. Also, what is the required behaviour if some sites in the site-group are set to PE-diverse and some are set to PoP-diverse? [SLI] Good catch :) We need to precise the expected behavior. 1) We can consider diversity type+site-group as a group ID. So having a sit= e A with pe-diverse group 10 and site B with pop-diverse group 10, will con= sider A and B not part of the same group, and no diversity will be applied = between them. 2) We allow for mixing. If we have site A,B,C with pe-diverse group 10 and = let's says that A is on PE1 PoP#1, B is on PE2 PoP#1, C is on PE3 PoP#4 ; n= ow we add a new site D with pop-diverse group 10, this means that D cannot = be implemented on PoP#1 and PoP#4. Any preference? * Sn 5.2.8.3: Similar question here: what is the expected behaviour if one access link is set to PE-diverse and one is set to PoP-diverse? Also is a "none" option needed, for when it's ok for both links to terminate at the same PE? [SLI] "None" option is when the container does not exist. Does it work ? In= this case yes, both can terminate on the same PE. * Sn 5.2.8.3: I think there is a problem with this way of specifying the availability behaviour based on access priorities. In the complex example in the last paragraph, it says that if A1 and A2 fail, the traffic will be load-shared on A3 and A4. However, if only A1 fails, the traffic would all be forced on to A2, right? This is unlikely to be desirable - probably what the customer wants is to always be load-sharing on 2 links, unless all of A1 - A4 fail (i.e., if only A1 fails, then load-share on A2 and A3). There doesn't seem to be a way to specify that using access priorities. Having said that, this may not be a problem in practice: the SPs in MEF all indicated that they never have more than 2 links to a given site. [SLI] We have some use case with more than two connections.=20 The problem you describe is true but it's linked to the design chosen (so c= ustomer has to adapt the capacity planning).=20 Most of the case I know are more multiple levels of backups, but the model = is flexible and can provide anykind of design, that's why we wanted to illu= strate it. * Sn 5.2.8.3.1: If I understand correctly, the difference between traffic protection enabled and disabled would be in how quickly the SP can restore traffic towards a site if one of the network-access links fails - is that correct? I'm not sure how useful this is without putting some numbers in here - i.e. if the customer pays extra for a service with traffic protection enabled, what traffic restoration speed is the SP targeting or guaranteeing? [SLI] traffic protection is typically implementation of fast reroute techno= logy. What SP is guaranteeing or not , is up to each SP ... Also, what is the expected behaviour if traffic protection is enabled on one network-access link but disabled on another? Shouldn't it be an attribute that applies to the site as a whole rather than to each network-access link separately? [SLI] We cannot really do it per site, due to the subVPN case where a subVP= N site may have it and others not. Agree that for multihoming, all logical access needs to have it. (I) For info: in MEF this would likely be covered by an SLS objective; it would be up to the SP to determine whether they needed to enable traffic protection or not in order to meet the SLS in the event of a link failure, rather than the customer requesting this explicitly. [SLI] That's also a good way to do it. The issue is that some customer really wants to be precise in what is imple= mented. * Sn 5.3.1: In RFC 4364, this is called "Carrier's carrier" rather than "Carrier supporting Carrier" - I think the latter is Cisco's name for the same feature. It would be better to use the RFC4364 name in this draft. [SLI] Ack Also in the yang module, it would be clearer to call the leaf "carriers-carrier" or similar, rather than "mpls". * Sn 5.3.2: Some of these constraints are not clearly defined. I assume that the latency and jitter constraints specify the maximum latency and jitter, whereas the bandwidth is the minimum bandwidth? Do these constraints apply to all received packets for all traffic classes? [SLI] It's independent of class of services. I do not understand the site diversity constraint - how would a path between 2 sites cross any other sites? Does it mean "are not crossing the same P routers"? Or does it mean that the paths are physically diverse? [SLI] If you consider a path between two PEs, it will cross multiple networ= k sites (where we host PEs or P routers). For example, a path between NY and LA will maybe cross CHI, DEN and LV. If we want another path with site diversity, we must avoid crossing CHI, DE= N and LV. (I) In MEF, I expect that all of these constraints would be covered by the SLS. * Sn 5.4: The text here mentions "if apply-template is done on service container of a site", and the example also shows a service container with an apply-template leaf - but in the yang module, there is no apply-template leaf in the service container. The yang only has apply-template for the site and for network-accesses. [SLI] We need to fix it. * Sn 6: As described in Sn 5.2.5, the routing protocol specified in the model applies to the SP-customer link; however, in the example described in this section, it is described as applying to the PE-CE link, even though the CE is provider-managed and so the SP-customer link is between the CE and the customer (e.g. it says "Routing protocols will also be configured on the PE, bgp will be used as requested in the service model.") In the provider-managed case, the routing protocol used between the CE and the PE would be internal to the provider and not specified in the model. [SLI] Agree, this is something that we missed to fix when we changed the ro= uting protocol scope from earlier version. Thanks for the catch. * Sn 8: What are the svc-input-bandwidth and svc-output-bandwidth? I think the svc-output-bandwidth may be related to the QoS profile (see earlier comments), but what is the svc-input-bandwidth for? [SLI] It's used in case of asymmetric BW media like ADSL. * Sn 8: If MPLS is enabled (i.e. the CsC case), does the svc-mtu value include the MPLS labels or just the IP packet? [SLI] it becomes MPLS BW because the service is no more IP. * Sn 8: Is there ever a case where the "list routing-protocol" can contain more than 2 entries (i.e., one for IPv4 and one for IPv6)? [SLI] You can use dynamic and static routing at the same time also. * Sn 8: For the ip-connection, how is the "subnet-only" case used? In this case, how are the SP's and the customer's addresses assigned and known? Also should the "subnet" choice apply only when the address-allocation-type is static (i.e., add a "when" statememt)? [SLI] Based on earlier mentioned point, I think we need to remove the subne= t only. * Sn 8: The OAM parameters are not described in Sn 5 - is this an omission? In the case of a holdtime specified with a profile, how would the customer know what the contents of the profile is? [SLI] That's a miss ... Thanks, David -- 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 Thu Apr 21 07:01:07 2016 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 BE74412DC91 for ; Thu, 21 Apr 2016 07:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.518 X-Spam-Level: X-Spam-Status: No, score=-15.518 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 LTz_CtwYutb8 for ; Thu, 21 Apr 2016 07:01:01 -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 D103212DAB1 for ; Thu, 21 Apr 2016 07:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33323; q=dns/txt; s=iport; t=1461247261; x=1462456861; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=VYsjQ9/H2NZxmSmBkeKZeIRqEPIGgL2cyifmlQs+uDk=; b=jRtiTnGTRcCQZTI0Biyn4UxiZMncjvSSxO/ZJOACmcjEoXW9d9Rr72xp kk2BLug3FrBtqjvwlBY5vORq/h8Rb817idhHd3HUYyuoV2MHn3zXse5cF CD+hj46mNuYTJTzDf5m3Q4y9PymBhxSVUOHLfSH190a81+J9DXeHkUIfN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQA23BhX/xbLJq1ehAt9uW8BDYFvB?= =?us-ascii?q?BcLhWwCgWkUAQEBAQEBAWUnhEEBAQEDAQEBARcBHS8HBAwHBAsRBAEBAQkeBw8?= =?us-ascii?q?CFh8JCAYBDAYCAQEViAkIDr9NAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIYRLh?= =?us-ascii?q?AUBCQsGAUqFKgEEjVOFS4RxiCxEhSSBZoRNgwaFV4YjiQoeAQFCggQFFYFLOzC?= =?us-ascii?q?HOggXgR0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208";a="676855741" 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; 21 Apr 2016 14:00:58 +0000 Received: from [10.63.23.138] (dhcp-ensft1-uk-vla370-10-63-23-138.cisco.com [10.63.23.138]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3LE0vfY012863; Thu, 21 Apr 2016 14:00:57 GMT To: stephane.litkowski@orange.com, "l3sm@ietf.org" References: <5717AB01.90908@cisco.com> <9485_1461225367_57188797_9485_1886_9_9E32478DFA9976438E7A22F69B08FF921BB091AF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: David Ball Message-ID: <5718DD19.10505@cisco.com> Date: Thu, 21 Apr 2016 15:00:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <9485_1461225367_57188797_9485_1886_9_9E32478DFA9976438E7A22F69B08FF921BB091AF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [L3sm] Feedback on L3SM draft X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 14:01:05 -0000 Thanks - additional comments inline (see [DB1]): On 21/04/2016 08:56, stephane.litkowski@orange.com wrote: > Hi, > > Thanks for the comment, please find inline comments. > > > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Wednesday, April 20, 2016 18:15 > To: l3sm@ietf.org > Subject: [L3sm] Feedback on L3SM draft > > Hi, > > I would like to introduce myself as the editor of the MEF IP Service Attributes project. In the MEF, we have been considering the latest L3SM draft (draft-ietf-l3sm-l3vpn-service-model-05) during the last quarter, and in that context and as requested in your recent liaison, I would like to provide some questions and comments. Note that this is my personal feedback, not that of MEF. > > Some of my comments are for information only (I have marked these with "(I)"). Many others are questions to ensure I have understood the model correctly - in these cases, as well as answering my questions, it may be useful to add additional explanation to the draft to help other readers, even if no changes are needed to the yang module itself. > > * (I) Abstract: It is stated here, and again in Sn 4, that the intent of > this model is that it can be instantiated by a management system in > the SP, i.e. it contains all of the info needed to allow the > management system to configure the SP's network elements so as to > correctly provision the service. > Note that this is similar, but not identical, to the focus of the MEF > work, which is to define the set of attributes that must be > contractually (or otherwise) agreed between the SP and the subscriber. > > * Sn 5: The "bearer" is described as refering to the physical properties > of the attachment, as opposed to the protocol oriented properties. > Are L2 aspects considered to be physical properties or protocol > oriented properties? For instance, suppose the attachment > is via a VLAN over an Ethernet LAG containing 2 physical Ethernet > interfaces: is the bearer the VLAN, the LAG, or the physical > interfaces? > > [SLI] The goal of the model is to focus on Layer 3. Bearer is just a reference to everything under layer 3, so as your example, VLAN is considered as bearer. > One "issue" we have to deal with in L3SM, is that we cannot manage all the access types as it's really different from one provider to the other and there are plenty of accesses. Moreover it's not really a L3VPN topic. > So two cases : > - the customer orders an access separately of the L3VPN site, in this case, the bearer reference needs to be attached, so the customer provides a reference to an existing access to the provider. > - the customer orders an access at the same time of the L3VPN site. The provider will need to provide an access type that fills the customer requirement in term of diversity, bandwidth, services ... > The first option is here just in case the customer does not want to use an automated access election procedure but wants a really specific access type. This makes me thing that an "always-on" boolean may be necessary for some backup scenario ... [DB1] Ok this makes sense - yes I agree trying to cover all the possible cases is challenging and not really in the scope of the L3 service. It would be useful to add a bit more explanation about this (I guess in Sn 5.2.7.1), in particular to mention that the bearer covers everything below layer 3. > * Sn 5.1.1.4: Could you add an example of when hub-and-spoke-disjoint is > used? Is it the same as having 2 hub-and-spoke VPNs where each hub > site belongs to a different VPN and all the spoke sites belong to both > VPNs? > [SLI] Yes this is similar to the case you mention. [DB1] Is it similar or the same? What is the difference? What I am asking about is the real-life case where you would need hub-and-spoke-disjoint. > * Sn 5.1.2: It is unclear to me how a Cloud identifier (e.g. "Cloud1") > is associated with a particular cloud service (say, Amazon Web > Services). > Is there an assumption that the management system that is > instantiating this yang model has auxilliary knowledge about the cloud > service that each Cloud ID is actually associated with (configured > by some means outside the scope of this model)? > [SLI] That's the point. OSS needs some knowledge about what is Cloud1 and Cloud2, this can be hardcoded or retrieved from another system. The same happens with standard QoS or encryption profiles ... > > For the subscriber to order a cloud service, they also need to know > what actual service each Cloud ID is associated with - is that also > assumed to be known by means outside this model? > [SLI] Provider can communicate to customer the list of CloudIDs to be used. Is that an issue ? [DB1] Ok - no that's not an issue, although it would be useful to say explicitly in the draft that the association is provided to the customer by some other means. > We cannot really define a list of clouds here ... I think we need to keep it flexible. > > > * Sn 5.1.4: I was a bit confused by the description of extranet. If > VPN A lists VPN B as an extranet, then the text states that the > relationship must be bi-directional. However, the site-role leaf > means that it is not necessarily symmetric. My interpretation is that > if VPN B has hub-and-spoke (or hub-and-spoke-disjoint) topology, then > sites in A might only be able to access certain sites in B (depending > on the specified role); however, those sites in B would always be able > to access all sites in A. Is this interpretation correct? > [SLI] Bi-directional does not mean symmetric here. It just mean that if you configure extranet in VPN A to access to VPN B, you don't need to configure the reverse (VPN B accessing to VPN A). Now in term of real communications between sites, the VPN topology will dictate it as you mentioned. [DB1] It would be useful to make that more explicit in the draft. > Presumably the requirements in Sn 5.2.1 are intended to also apply to > the site-role leaf for the extranet, in respect of the topology of the > VPN listed as the extranet? It would be good to state that > explicitly. > [SLI] Yes for sure. Will enhance text in future revision. > > > * Sn 5.2.2.1.2: In the case of a site connected to multiple VPNs, how is > traffic received from the site mapped to the right VPN? > It is important to know which VPN the traffic maps to, not only to > ensure it is sent to the right destination, but also because different > VPNs might have different bandwidth or performance attributes. > > [SLI] No, attributes you are referring to are sites attributes, not VPN attributes. > In multiVPN scenario, the same logical access is used to access to all VPNs : for instance, bandwidth is shared. [DB1] Sorry I was unclear; I was thinking of things like the bandwidth or latency transport constraints, which are per VPN. > As described later on (Sn 5.2.2.2), a VPN policy can be used with a > filter that limits the LANs that belong to each VPN (which implies > that a packet can be mapped to a VPN based on its source address); > [SLI] Yes and no, from a service point of view, this can be seen as source based VPN association. > Now, in reality (device implementation), it's still a destination based association, each LAN will be advertised with a different RT, so the return traffic is using a different VPN. [DB1] Right, it is the service definition perspective I am most concerned with. > however, I don't think there is a requirement that filters are used to > ensure that each possible LAN only belongs to a single VPN. Is the > intention that filters are used to partition the LANs, or can a packet > with a given source address potentially belong to multiple VPNs? > [SLI] There is no limitation here, each LAN can belong to a single VPN, or a LAN can belong to multiple VPNs, or just some ... For instance, one use case (at least for us) is ToIP, where only Voice LANs need to be part of a customer Voice VPN, and the others are belonging to the regular customer IPVPN. > > If so, is the implication that the destination address is looked up in > each VPN? Is it possible that a route to the destination exists in > multiple VPNs? How is the order of the VPNs in which to perform the > lookups determined in that case? > For instance, looking at the first example in Sn 5.2.2.2.2 (VPN > policy), when a packet is received from VPN3_Site2 at PE6, how does > PE6 determine whether to handle the packet as part of VPN2 or VPN3? > [SLI] The IP destination is used. The destination IP can be part of VPN2 or VPN3. [DB1] Can the destination be part of VPN2 and VPN3? If so, how does the PE determine which to use? > * Sn 5.2.2.1.3: Both from the perspective of what the management system > needs to know to provision the SPs network, and from what needs to be > agreed between the SP an the customer, this "Sub VPN attachment" case > seems to be indistinguishable from treating it as separate sites. The > text says: "It is similar than having separate sites instead that the > customer wants to share some physical components while keeping strong > isolation". However, from a service definition perspective, whether > two separate sites happen to share the same physical infrastructure is > immaterial, and in fact this could (or should) be invisible to the SP. > I don't understand what additional value this "Sub VPN attachment" > case provides. > > [SLI] This is a discussion we already had about how to model SubVPN. > Considering them as separate sites was evaluated but there was some need to correlate > sites that belongs the the same sub-VPN. This is particularly true when the SP provides the access. > The SP needs to know that the IP sites must be built on the same access. [DB1] Would this be captured by them both refering to the same bearer (or to a bearer that ultimately maps to the same access)? > * Sn 5.2.3.1: In the case of a service-provider defined template, how > would the customer be aware of what the template contains? Is it > assumed to be made available by some mechanism outside the scope of > this yang module? > > [SLI] The idea to have customer to create template, not really the provider. [DB1] The text says "a service provider defined template", so if that's not the intent then it probably needs to be updated. In any case, the same question would exist the other way round: if the customer creates the template, how would the provider know what's in it? I guess this is the same as the cloud IDs and QoS profiles, it's some mechanism outside the scope of the yang, right? > * Sn 5.2.4: I think there is a conflict between the definitions in > section 2 and the values described in this section. According to > section 2, the "CE" is on the customer side of the SP-customer > boundary, which I take to mean it is owned and managed by the > customer. Given this definition, it would seem that a > "provider-managed" service is impossible - if the provider manages a > CPE device that is not VPN aware, then that is not the "CE" according > to the definitions in section 2, it is the "PE". The definitions in > section 2 don't seem to align with what is normally understood by "PE" > and "CE" in this case. > > [SLI] Agree, my mistake, I will need to update definitions in Section 2. > It was a bad copy/paste. [DB1] Ok, thanks. > Furthermore, section 3 limits the scope of the model to BGP PE-Based > VPNs, so this case - where the "PE" (per section 2) is a CPE that is > not VPN aware - is out of scope per Sn 3. > [SLI] Not sure to catch the case you mention here .. [DB1] Never mind, I think if you fix the definitions that will cover this. > I don't think that is the intent; this situation is clearly intended > to be in scope (especially as this is exactly the case described by > the example in Sn 6); so I think either the definitions in Sn 2 or the > scope statement in Sn 3 (or both) need to be modified. > Note that this impacts several other parts of the document: e.g. 5.2.5 > refers to a "CE-customer" boundary, 5.2.7.2 refers to a "CE to LAN > connection", etc - neither of which makes sense given the current > definitions in section 2. On the other hand, changing the definitions > may also have other impacts, e.g. site diversity, acccess diversity, > traffic protection, etc are described in terms of the CE-PE links, but > for provider-managed sites perhaps they are intended to apply to the > CE-customer links (or perhaps not)? > [SLI] CE is located at customer premise whatever the management model. > Site diversity ... always refers to CE-PE connection (customer site to provider network). [DB1] Ok - so in the provider-managed case, this is giving the customer visibility into the provider's network? > * Sn 5.2.4: Assuming the above problem is fixed, it is not clear what > "comanaged" means or how that affects the rest of the model. Where is > the demarcation between the SP and the subscriber in this case? > Also, in the case of provider-managed, wouldn't the management address > (of the CE??) be internal to the SP (i.e., it could be allocated in a > similar way to RTs and RDs)? It's not something the customer needs to > be aware of, right? > [SLI] > co-managed means that it's provided and managed by the SP , but the customer can access it. > Demarcation is the same as provider managed case. I will add more text to precise it. [DB1] Ok, thanks. > * (I) Sn 5.2.5: For information, MEF members indicated that several > other protocols are in use that would need to be added to this list > (in particular, ISIS and EIGRP). > > [SLI] IS-IS as PE-CE ? [DB1] Yes. > EIGRP is not really a standard protocol, it can be added through augmentation I think, a bit like HSRP. [DB1] Yes fair enough. :) > * Sn 5.2.5.2: In this case, is the implication that the customer uses a > default route towards the SP? How does the customer determine the > gateway address to use? > (Same question also applies in the VRRP and static cases). > > [SLI] Good point, the subnet-only option for static allocation of IP addresses causes an issue here. > If customer uses "addresses" container, it allocates provider address so he knows the gateway. > With dynamic allocation, like DHCP, gateway can be learned. > We can remove the subnet-only option. [DB1] Ok - yes the subnet-only option caused us a lot of confusion so removing it would be good! It would also be useful to say explicitly that the provider address or the address learnt through DHCP/SLAAC should be used as the default gateway when the routing protocol is set to "static" or "direct". > * Sn 5.2.5.2: This seems to be describing a case where the SP-customer > link could be a multipoint link; for example, where the SP provides a > WiFi access point to a residential subscriber. Is that right? > [SLI] Why multipoint ? [DB1] In this case, the wifi access point would be a provider-managed CE. The customer could have multiple devices that connect to the CE over wifi; so, the SP-customer link is a multipoint connection. (Note the CE is provider-managed in this example, so the SP-customer link is not the PE-CE link; the PE-CE link might still be P2P). > It seems like there would need to be several other restrictions in > this case - for example, the connection addressing would need to be > DHCP or SLAAC (since the static option can only be used to provide a > single address for the customer), and this likely only applies to > provider-managed sites. Some P2P aspects like BFD and encryption > would need to be disabled. > > * (I) Sn 5.2.5.3: The use of VRRP should be invisible to the customer; > so this is an example of something that does not need to be agreed > between the SP and the customer, but which the management system in > the SP needs to provision in the PEs. > [SLI] VRRP case is a bit tricky. > This is the case where customer has direct LAN connections multihomed to two PEs, so there are two logical accesses. [DB1] There are certainly 2 L2 links, but you could view it as a single L3 link (since the two PEs must also have L2 connectivity between them over the same LAN), and hence a single logical access. From the CE's perspective, it only sees a single L3 peer (just one who's corresponding MAC address keeps changing). Of course, from the provider's perspective, there are definitely 2 PEs... > Now the customer wants only direct routing but with redundancy. > I think we can deduce from routing protocol=direct + presence of the availability container that we need to implement VRRP. > Does it work for you ? [DB1] Yes, that would work; alternatively, it could be covered as part of the bearer, or maybe even an explicit VRRP boolean under the network-access. > * Sn 5.2.6.1: The QoS profile is described as the "outgoing QoS profile > to be applied" - if I understand that correctly, it means the QoS > profile only specifies egress policing, it does not specify any > ingress policing - is that correct? > > [SLI] Yes, only egress policing. > > > * Sn 5.2.6.1.2: In the case of standard profiles, how does the > customer know what they are? Is that assumed to be done by means > outside the scope of this yang module? > [SLI] Yes communication needed between SP and customer. [DB1] It would be useful to make that explicit. > Also, the priority relates to strict priority queuing - is strict > priority queuing required when this yang module is used, or can other > mechanisms also be used? > [SLI] The exact mechanism to be used does not really care here. > From a service point of view, we provide multiple level of priorities, and within each level, we can provide a guaranteed bandwidth. [DB1] That makes sense. The text says "Priority-level is used to define strict priority queueing." - perhaps changing "is" to "can be" would soften this a little? > * Sn 5.2.6.1.2: The rate-limit is described as "a percentage of the > global service bandwidth" - is the "global service bandwidth" the > value specified in the "svc-output-bandwidth" leaf? > Similarly, the guaranteed-bw-percent is "expressed as a percentage", > but it doesn't say what it is a percentage of. Is this also a > percentage of the value in the "svc-output-bandwidth" leaf? > [SLI] Yes it's a percentage of svc-output-bandwidth or input-bandwidth (depending if the access is symmetric in term of BW or not). > I will add more text to precise it. [DB1] If it is egress policing only, wouldn't it always be the svc-output-bandwidth? When would svc-input-bandwidth be used? > * Sn 5.2.7: Some parameters can be configured at the site level or at > the network-access level; but it seems like certain parameters only > make sense at one or the other; for example, it is unlikely you would > want different routing protocols on different network access links, > but you might want to assign different metrics to different links. > How is this handled? > [SLI] Well, this was an old discussion also. > It looks that there is some SP using different protocols in multihoming scenarios (ex : BGP on one side, static on the other, or OSPF ...). That explain why we need routing protocol container at site network access level. [DB1] Ok. > * Sn 5.2.7.2.1: In the case of DHCP (or SLAAC), is the assumption that > it is used to provide (at least) the customer address, subnet mask and > default gateway address? > Also is there an assumption that a static-address is used in the case > where the routing protocol is BGP? > [SLI] Yes, we can precise it. [DB1] Thanks. > * Sn 5.2.8: I found this description unclear - is the intent that this > information is all internal to the SP, and used to give information to > the management system; or is it intended to be a way for the customer > to provide hints to the SP, which the SP may choose to ignore? > [SLI] That's the point. > Service placement is up to the SP but customer can influence it especially for the diversity purpose. > In case the SP provides diversity service it needs to fill it and must not ignore it. > > * Sn 5.2.8: My reading of this paragraph is that the SP can decide how > to connect each site based on any constraint, and that the ones listed > here are optional and are to be treated as hints by the management > system. However, some of the following subsections have hard > requirements (MUSTs). What is the intent here? > [SLI] Diversity constraint is a constraint that the SP cannot ignore. > After that SP is free to place the service based on its own policy. [DB1] Ok - maybe need a tweak to the text to make that clearer? > * Sn 5.2.8.2: I am not sure how to interpret these requirements if the > sites have more than one network-access link (to different PEs). > Do they mean that two sites in the same site-group must have at least > one network-access link to a different PE/PoP, or that the PEs/PoPs > that network-access links connect to must be completely disjoint sets? > > [SLI] PEs/PoPs must be completely disjoint set. But I could agree that this is strong. > In case of multihoming, "pe-diverse" applies between site-network-accesses. > > Or do they only apply to sites with a single network-access link? > [SLI] No, that should work with multihomed. [DB1] Ok, I think this should be made clearer in the requirements - the existing text just refers to sites not to site-network-accesses. > If two sites both have two network-accesses, then even if they are > connected to the same 2 PEs, a PE failure would not impact > connectivity to them or between them. > For example, is it allowed to have site A connected to PE 1 and PE 2, > and site B connected to PE 2 and PE 3, if they both are set to PE > diverse and are in the same site group? What if site B is connected > to PE 1 and PE 2? > [SLI] Customer does not require diversity in this case, because diversity is already provided by multihoming which is "pe-diverse" by default. [DB1] Agreed - but if an SP gets a request from the customer that asks for site diversity, they still need to know what to do with it. From the above, it looks like neither of these cases would be allowed, right? > Also, what is the required behaviour if some sites in the site-group > are set to PE-diverse and some are set to PoP-diverse? > [SLI] Good catch :) > We need to precise the expected behavior. > 1) We can consider diversity type+site-group as a group ID. So having a site A with pe-diverse group 10 and site B with pop-diverse group 10, will consider A and B not part of the same group, and no diversity will be applied between them. > 2) We allow for mixing. If we have site A,B,C with pe-diverse group 10 and let's says that A is on PE1 PoP#1, B is on PE2 PoP#1, C is on PE3 PoP#4 ; now we add a new site D with pop-diverse group 10, this means that D cannot be implemented on PoP#1 and PoP#4. > Any preference? [DB1] No personal preference; option 1 is simpler, but option 2 seems ok too. I think option 2 means: any site in the group that is set to pop-diverse must not share a PoP with any other site in the group, but 2 sites in the group that are both pe-diverse could be on different PEs in the same PoP, right? > * Sn 5.2.8.3: Similar question here: what is the expected behaviour if > one access link is set to PE-diverse and one is set to PoP-diverse? [DB1] I think this case could be fixed by making this a per-site attribute rather than a per-network-access attribute. > Also is a "none" option needed, for when it's ok for both links to > terminate at the same PE? > [SLI] "None" option is when the container does not exist. Does it work ? In this case yes, both can terminate on the same PE. [DB1] Ah, ok - that definitely needs to be mentioned! > * Sn 5.2.8.3: I think there is a problem with this way of specifying > the availability behaviour based on access priorities. In the complex > example in the last paragraph, it says that if A1 and A2 fail, the > traffic will be load-shared on A3 and A4. However, if only A1 fails, > the traffic would all be forced on to A2, right? This is unlikely to > be desirable - probably what the customer wants is to always be > load-sharing on 2 links, unless all of A1 - A4 fail (i.e., if only A1 > fails, then load-share on A2 and A3). There doesn't seem to be a way > to specify that using access priorities. > Having said that, this may not be a problem in practice: the SPs in > MEF all indicated that they never have more than 2 links to a given > site. > > [SLI] We have some use case with more than two connections. > The problem you describe is true but it's linked to the design chosen (so customer has to adapt the capacity planning). > Most of the case I know are more multiple levels of backups, but the model is flexible and can provide anykind of design, that's why we wanted to illustrate it. [DB1] I'm not sure I understand this. How would this model provide the design I described? > * Sn 5.2.8.3.1: If I understand correctly, the difference between > traffic protection enabled and disabled would be in how quickly the SP > can restore traffic towards a site if one of the network-access links > fails - is that correct? I'm not sure how useful this is without > putting some numbers in here - i.e. if the customer pays extra for > a service with traffic protection enabled, what traffic restoration > speed is the SP targeting or guaranteeing? > > [SLI] traffic protection is typically implementation of fast reroute technology. > What SP is guaranteeing or not , is up to each SP ... [DB1] Yes of course, but the customer needs to know what it is. Maybe that's outside the scope of the yang module? > Also, what is the expected behaviour if traffic protection is enabled > on one network-access link but disabled on another? Shouldn't it be > an attribute that applies to the site as a whole rather than to each > network-access link separately? > [SLI] We cannot really do it per site, due to the subVPN case where a subVPN site may have it and others not. > Agree that for multihoming, all logical access needs to have it. [DB1] Ok - so we still need to define what happens if one has it and another doesn't, right? > (I) For info: in MEF this would likely be covered by an SLS objective; > it would be up to the SP to determine whether they needed to enable > traffic protection or not in order to meet the SLS in the event of a > link failure, rather than the customer requesting this explicitly. > > [SLI] That's also a good way to do it. > The issue is that some customer really wants to be precise in what is implemented. > > * Sn 5.3.1: In RFC 4364, this is called "Carrier's carrier" rather than > "Carrier supporting Carrier" - I think the latter is Cisco's name for > the same feature. It would be better to use the RFC4364 name in this > draft. > [SLI] Ack > > Also in the yang module, it would be clearer to call the leaf > "carriers-carrier" or similar, rather than "mpls". > > * Sn 5.3.2: Some of these constraints are not clearly defined. I assume > that the latency and jitter constraints specify the maximum latency > and jitter, whereas the bandwidth is the minimum bandwidth? Do these > constraints apply to all received packets for all traffic classes? > [SLI] It's independent of class of services. > > I do not understand the site diversity constraint - how would a > path between 2 sites cross any other sites? Does it mean "are not > crossing the same P routers"? Or does it mean that the paths are > physically diverse? > [SLI] If you consider a path between two PEs, it will cross multiple network sites (where we host PEs or P routers). > For example, a path between NY and LA will maybe cross CHI, DEN and LV. > If we want another path with site diversity, we must avoid crossing CHI, DEN and LV. [DB1] Ok, that makes sense - I was confused because everywhere else in the document, "site" means "customer site" but here it is being used with a different meaning. Could we use a different word here? Would "PoP" work? > (I) In MEF, I expect that all of these constraints would be covered by > the SLS. > > * Sn 5.4: The text here mentions "if apply-template is done on service > container of a site", and the example also shows a service container > with an apply-template leaf - but in the yang module, there is no > apply-template leaf in the service container. The yang only has > apply-template for the site and for network-accesses. > [SLI] We need to fix it. > > * Sn 6: As described in Sn 5.2.5, the routing protocol specified in the > model applies to the SP-customer link; however, in the example > described in this section, it is described as applying to the PE-CE > link, even though the CE is provider-managed and so the SP-customer > link is between the CE and the customer (e.g. it says "Routing > protocols will also be configured on the PE, bgp will be used as > requested in the service model.") In the provider-managed case, the > routing protocol used between the CE and the PE would be internal to > the provider and not specified in the model. > > [SLI] Agree, this is something that we missed to fix when we changed the routing protocol scope from earlier version. > Thanks for the catch. > > > * Sn 8: What are the svc-input-bandwidth and svc-output-bandwidth? I > think the svc-output-bandwidth may be related to the QoS profile (see > earlier comments), but what is the svc-input-bandwidth for? > [SLI] It's used in case of asymmetric BW media like ADSL. > > * Sn 8: If MPLS is enabled (i.e. the CsC case), does the svc-mtu value > include the MPLS labels or just the IP packet? > > [SLI] it becomes MPLS BW because the service is no more IP. [DB1] Ok - can you clarify that in the text? > * Sn 8: Is there ever a case where the "list routing-protocol" can > contain more than 2 entries (i.e., one for IPv4 and one for IPv6)? > > [SLI] You can use dynamic and static routing at the same time also. [DB1] Ah yes, that makes sense. > * Sn 8: For the ip-connection, how is the "subnet-only" case used? In > this case, how are the SP's and the customer's addresses assigned and > known? > Also should the "subnet" choice apply only when the > address-allocation-type is static (i.e., add a "when" statememt)? > > [SLI] Based on earlier mentioned point, I think we need to remove the subnet only. [DB1] Ok. > * Sn 8: The OAM parameters are not described in Sn 5 - is this an > omission? > In the case of a holdtime specified with a profile, how would the > customer know what the contents of the profile is? > [SLI] That's a miss ... [DB1] Ok. Thanks! David > > Thanks, > > > David > > -- > 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 confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > -- David Ball From nobody Thu Apr 21 08:26:51 2016 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 5DA6E12EB55 for ; Thu, 21 Apr 2016 08:26:48 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xaarwexxN42S for ; Thu, 21 Apr 2016 08:26:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174B712EB1B for ; Thu, 21 Apr 2016 08:26:44 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 71E392DC1A8; Thu, 21 Apr 2016 17:26:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.17]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 4C6D34C048; Thu, 21 Apr 2016 17:26:42 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0279.002; Thu, 21 Apr 2016 17:26:42 +0200 From: To: David Ball , "l3sm@ietf.org" Thread-Topic: [L3sm] Feedback on L3SM draft Thread-Index: AQHRmx/OuCnEXvw7QESYANDcSs89x5+T8EpQgABkY4CAACMs4A== Date: Thu, 21 Apr 2016 15:26:40 +0000 Message-ID: <3217_1461252402_5718F132_3217_10280_3_9E32478DFA9976438E7A22F69B08FF921BB0A7FA@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <5717AB01.90908@cisco.com> <9485_1461225367_57188797_9485_1886_9_9E32478DFA9976438E7A22F69B08FF921BB091AF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5718DD19.10505@cisco.com> In-Reply-To: <5718DD19.10505@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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.21.144517 Archived-At: Subject: Re: [L3sm] Feedback on L3SM draft X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 15:26:48 -0000 More inline , I stripped the agreed part -----Original Message----- From: David Ball [mailto:daviball@cisco.com]=20 Sent: Thursday, April 21, 2016 16:01 To: LITKOWSKI Stephane OBS/OINIS; l3sm@ietf.org Subject: Re: [L3sm] Feedback on L3SM draft Thanks - additional comments inline (see [DB1]): On 21/04/2016 08:56, stephane.litkowski@orange.com wrote: > Hi, > > Thanks for the comment, please find inline comments. > > > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Wednesday, April 20, 2016 18:15 > To: l3sm@ietf.org > Subject: [L3sm] Feedback on L3SM draft > > * Sn 5.1.1.4: Could you add an example of when hub-and-spoke-disjoint is > used? Is it the same as having 2 hub-and-spoke VPNs where each hub > site belongs to a different VPN and all the spoke sites belong to both > VPNs? > [SLI] Yes this is similar to the case you mention. [DB1] Is it similar or the same? What is the difference? What I am asking about is the real-life case where you would need hub-and-s= poke-disjoint. [SLI2] From a service point of view, it's the same. From an implementation = point of view, you can implement hub-spoke-disjoint in multiple ways. I think there are very few use case (I remember at least one :) ), but this= exist. > For the subscriber to order a cloud service, they also need to know > what actual service each Cloud ID is associated with - is that also > assumed to be known by means outside this model? > [SLI] Provider can communicate to customer the list of CloudIDs to be use= d. Is that an issue ? [DB1] Ok - no that's not an issue, although it would be useful to say explicitly = in the draft that the association is provided to the customer by some other= means. [SLI2] I already updated the draft with a new paragraph regarding the exter= nal identifiers. > We cannot really define a list of clouds here ... I think we need to keep= it flexible. > > > * Sn 5.1.4: I was a bit confused by the description of extranet. If > VPN A lists VPN B as an extranet, then the text states that the > relationship must be bi-directional. However, the site-role leaf > means that it is not necessarily symmetric. My interpretation is that > if VPN B has hub-and-spoke (or hub-and-spoke-disjoint) topology, then > sites in A might only be able to access certain sites in B (depending > on the specified role); however, those sites in B would always be able > to access all sites in A. Is this interpretation correct? > [SLI] Bi-directional does not mean symmetric here. It just mean that if y= ou configure extranet in VPN A to access to VPN B, you don't need to config= ure the reverse (VPN B accessing to VPN A). Now in term of real communicati= ons between sites, the VPN topology will dictate it as you mentioned. [DB1] It would be useful to make that more explicit in the draft. [SLI2] Done > Presumably the requirements in Sn 5.2.1 are intended to also apply to > the site-role leaf for the extranet, in respect of the topology of the > VPN listed as the extranet? It would be good to state that > explicitly. > [SLI] Yes for sure. Will enhance text in future revision. > > > * Sn 5.2.2.1.2: In the case of a site connected to multiple VPNs, how is > traffic received from the site mapped to the right VPN? > It is important to know which VPN the traffic maps to, not only to > ensure it is sent to the right destination, but also because different > VPNs might have different bandwidth or performance attributes. > > [SLI] No, attributes you are referring to are sites attributes, not VPN a= ttributes. > In multiVPN scenario, the same logical access is used to access to all VP= Ns : for instance, bandwidth is shared. [DB1] Sorry I was unclear; I was thinking of things like the bandwidth or latency= transport constraints, which are per VPN. [SLI2] In multiVPN case, in most of the case you have a multiVPN site that= will take to different destination that are not part of the same multiVPN. As an example, let's take site #1 which is multiVPN in VPN#A and #B. We hav= e site#2 which is multiVPN #A and #C and site#3 which is multiVPN #B and #D. If VPN#A express a transport constraint for site#1 <-> site#2, there is no = ambiguity : for example, in VRF where site#1 is connected, there will be a = TE tunnel to reach the PE connecting site#2 and BGP resolution will be done= through this TE tunnel. There is a "technical complexity" where site#1 is multiVPN in A and B and s= ite#2 is multiVPN in A and B also with different transport constraint expre= ssed in VPN A and B between the two sites. Honestly this does not really ma= ke sense IMO. But policy based routing (including source based) is necessa= ry at ingress to map to the correct TE tunnel (only in case LAN is used to = identity the VPN belonging). > If so, is the implication that the destination address is looked up in > each VPN? Is it possible that a route to the destination exists in > multiple VPNs? How is the order of the VPNs in which to perform the > lookups determined in that case? > For instance, looking at the first example in Sn 5.2.2.2.2 (VPN > policy), when a packet is received from VPN3_Site2 at PE6, how does > PE6 determine whether to handle the packet as part of VPN2 or VPN3? > [SLI] The IP destination is used. The destination IP can be part of VPN2 = or VPN3. [DB1] Can the destination be part of VPN2 and VPN3? If so, how does the PE determine which to use? [SLI2] In L3VPN, it's a single route to reach the destination in both VPNs,= so there is no need to choose. > * Sn 5.2.2.1.3: Both from the perspective of what the management system > needs to know to provision the SPs network, and from what needs to be > agreed between the SP an the customer, this "Sub VPN attachment" case > seems to be indistinguishable from treating it as separate sites. The > text says: "It is similar than having separate sites instead that the > customer wants to share some physical components while keeping strong > isolation". However, from a service definition perspective, whether > two separate sites happen to share the same physical infrastructure is > immaterial, and in fact this could (or should) be invisible to the SP. > I don't understand what additional value this "Sub VPN attachment" > case provides. > > [SLI] This is a discussion we already had about how to model SubVPN. > Considering them as separate sites was evaluated but there was some=20 > need to correlate sites that belongs the the same sub-VPN. This is partic= ularly true when the SP provides the access. > The SP needs to know that the IP sites must be built on the same access. [DB1] Would this be captured by them both refering to the same bearer (or to a be= arer that ultimately maps to the same access)? [SLI2] Yes > * Sn 5.2.3.1: In the case of a service-provider defined template, how > would the customer be aware of what the template contains? Is it > assumed to be made available by some mechanism outside the scope of > this yang module? > > [SLI] The idea to have customer to create template, not really the provid= er. [DB1] The text says "a service provider defined template", so if that's not the i= ntent then it probably needs to be updated. In any case, the same question would exist the other way round: if the cust= omer creates the template, how would the provider know what's in it? I gue= ss this is the same as the cloud IDs and QoS profiles, it's some mechanism = outside the scope of the yang, right? [SLI2] There is a misnaming here, it's bit a template (like site-template),= it's a profile, like for cloud-access it requires external communication. > I don't think that is the intent; this situation is clearly intended > to be in scope (especially as this is exactly the case described by > the example in Sn 6); so I think either the definitions in Sn 2 or the > scope statement in Sn 3 (or both) need to be modified. > Note that this impacts several other parts of the document: e.g. 5.2.5 > refers to a "CE-customer" boundary, 5.2.7.2 refers to a "CE to LAN > connection", etc - neither of which makes sense given the current > definitions in section 2. On the other hand, changing the definitions > may also have other impacts, e.g. site diversity, acccess diversity, > traffic protection, etc are described in terms of the CE-PE links, but > for provider-managed sites perhaps they are intended to apply to the > CE-customer links (or perhaps not)? > [SLI] CE is located at customer premise whatever the management model. > Site diversity ... always refers to CE-PE connection (customer site to pr= ovider network). [DB1] Ok - so in the provider-managed case, this is giving the customer visibilit= y into the provider's network? [SLI2] Why do you think that ? > * (I) Sn 5.2.5: For information, MEF members indicated that several > other protocols are in use that would need to be added to this list > (in particular, ISIS and EIGRP). > > [SLI] IS-IS as PE-CE ? [DB1] Yes. [SLI2] This requires a more global consensus I think ... > * Sn 5.2.5.2: In this case, is the implication that the customer uses a > default route towards the SP? How does the customer determine the > gateway address to use? > (Same question also applies in the VRRP and static cases). > > [SLI] Good point, the subnet-only option for static allocation of IP addr= esses causes an issue here. > If customer uses "addresses" container, it allocates provider address so = he knows the gateway. > With dynamic allocation, like DHCP, gateway can be learned. > We can remove the subnet-only option. [DB1] Ok - yes the subnet-only option caused us a lot of confusion so removing it= would be good! It would also be useful to say explicitly that the provider address or the = address learnt through DHCP/SLAAC should be used as the default gateway whe= n the routing protocol is set to "static" or "direct". [SLI2] Ok > * Sn 5.2.5.2: This seems to be describing a case where the SP-customer > link could be a multipoint link; for example, where the SP provides a > WiFi access point to a residential subscriber. Is that right? > [SLI] Why multipoint ? [DB1] In this case, the wifi access point would be a provider-managed CE. The cus= tomer could have multiple devices that connect to the CE over wifi; so, the= SP-customer link is a multipoint connection. (Note the CE is provider-managed in this example, so the SP-customer link i= s not the PE-CE link; the PE-CE link might still be P2P). [SLI2] Today we only manage P2P connection. > * (I) Sn 5.2.5.3: The use of VRRP should be invisible to the customer; > so this is an example of something that does not need to be agreed > between the SP and the customer, but which the management system in > the SP needs to provision in the PEs. > [SLI] VRRP case is a bit tricky. > This is the case where customer has direct LAN connections multihomed to = two PEs, so there are two logical accesses. [DB1] There are certainly 2 L2 links, but you could view it as a single L3 link (= since the two PEs must also have L2 connectivity between them over the same= LAN), and hence a single logical access. From the CE's perspective, it on= ly sees a single L3 peer (just one who's corresponding MAC address keeps ch= anging). Of course, from the provider's perspective, there are definitely = 2 PEs... [SLI2] When using VRRP, you have two layer 3 accesses and on top you will a= dd the redundancy with a VIP. > Now the customer wants only direct routing but with redundancy. > I think we can deduce from routing protocol=3Ddirect + presence of the av= ailability container that we need to implement VRRP. > Does it work for you ? [DB1] Yes, that would work; alternatively, it could be covered as part of the bea= rer, or maybe even an explicit VRRP boolean under the network-access. > Also, the priority relates to strict priority queuing - is strict > priority queuing required when this yang module is used, or can other > mechanisms also be used? > [SLI] The exact mechanism to be used does not really care here. > From a service point of view, we provide multiple level of priorities, a= nd within each level, we can provide a guaranteed bandwidth. [DB1] That makes sense. The text says "Priority-level is used to define strict p= riority queueing." - perhaps changing "is" to "can be" would soften this a = little? [SLI2] Ok > * Sn 5.2.6.1.2: The rate-limit is described as "a percentage of the > global service bandwidth" - is the "global service bandwidth" the > value specified in the "svc-output-bandwidth" leaf? > Similarly, the guaranteed-bw-percent is "expressed as a percentage", > but it doesn't say what it is a percentage of. Is this also a > percentage of the value in the "svc-output-bandwidth" leaf? > [SLI] Yes it's a percentage of svc-output-bandwidth or input-bandwidth (d= epending if the access is symmetric in term of BW or not). > I will add more text to precise it. [DB1] If it is egress policing only, wouldn't it always be the svc-output-bandwid= th? When would svc-input-bandwidth be used? [SLI2] If you think PE-CE, output-bw will be used on CE side (CE to PE), in= put will be used at PE side (PE to CE). > * Sn 5.2.8: I found this description unclear - is the intent that this > information is all internal to the SP, and used to give information to > the management system; or is it intended to be a way for the customer > to provide hints to the SP, which the SP may choose to ignore? > [SLI] That's the point. > Service placement is up to the SP but customer can influence it especiall= y for the diversity purpose. > In case the SP provides diversity service it needs to fill it and must no= t ignore it. > > * Sn 5.2.8: My reading of this paragraph is that the SP can decide how > to connect each site based on any constraint, and that the ones listed > here are optional and are to be treated as hints by the management > system. However, some of the following subsections have hard > requirements (MUSTs). What is the intent here? > [SLI] Diversity constraint is a constraint that the SP cannot ignore. > After that SP is free to place the service based on its own policy. [DB1] Ok - maybe need a tweak to the text to make that clearer? [SLI2] Done > * Sn 5.2.8.2: I am not sure how to interpret these requirements if the > sites have more than one network-access link (to different PEs). > Do they mean that two sites in the same site-group must have at least > one network-access link to a different PE/PoP, or that the PEs/PoPs > that network-access links connect to must be completely disjoint sets? > > [SLI] PEs/PoPs must be completely disjoint set. But I could agree that th= is is strong. > In case of multihoming, "pe-diverse" applies between site-network-accesse= s. > > Or do they only apply to sites with a single network-access link? > [SLI] No, that should work with multihomed. [DB1] Ok, I think this should be made clearer in the requirements - the existing = text just refers to sites not to site-network-accesses. [SLI2] I added more text in the site-network-access part. > If two sites both have two network-accesses, then even if they are > connected to the same 2 PEs, a PE failure would not impact > connectivity to them or between them. > For example, is it allowed to have site A connected to PE 1 and PE 2, > and site B connected to PE 2 and PE 3, if they both are set to PE > diverse and are in the same site group? What if site B is connected > to PE 1 and PE 2? > [SLI] Customer does not require diversity in this case, because diversity= is already provided by multihoming which is "pe-diverse" by default. [DB1] Agreed - but if an SP gets a request from the customer that asks for site d= iversity, they still need to know what to do with it. From the above, it l= ooks like neither of these cases would be allowed, right? [SLI2] If customer requests diversity with multihoming, diversity will be e= nforced in addition to multihoming diversity leading to stronger constraint. I will add more text to explain it. > Also, what is the required behaviour if some sites in the site-group > are set to PE-diverse and some are set to PoP-diverse? > [SLI] Good catch :) > We need to precise the expected behavior. > 1) We can consider diversity type+site-group as a group ID. So having a s= ite A with pe-diverse group 10 and site B with pop-diverse group 10, will c= onsider A and B not part of the same group, and no diversity will be applie= d between them. > 2) We allow for mixing. If we have site A,B,C with pe-diverse group 10 an= d let's says that A is on PE1 PoP#1, B is on PE2 PoP#1, C is on PE3 PoP#4 ;= now we add a new site D with pop-diverse group 10, this means that D canno= t be implemented on PoP#1 and PoP#4. > Any preference? [DB1] No personal preference; option 1 is simpler, but option 2 seems ok too.=20= =20 I think option 2 means: any site in the group that is set to pop-diverse mu= st not share a PoP with any other site in the group, but 2 sites in the gro= up that are both pe-diverse could be on different PEs in the same PoP, righ= t? [SLI] Right, I will clarify with option 2 > * Sn 5.2.8.3: Similar question here: what is the expected behaviour if > one access link is set to PE-diverse and one is set to PoP-diverse? [DB1] I think this case could be fixed by making this a per-site attribute rather= than a per-network-access attribute. [SLI2] We cannot remove diversity from site-network-access as it is require= d for multihoming. > Also is a "none" option needed, for when it's ok for both links to > terminate at the same PE? > [SLI] "None" option is when the container does not exist. Does it work ? = In this case yes, both can terminate on the same PE. [DB1] Ah, ok - that definitely needs to be mentioned! [SLI2] Thinking more about it, I finally prefer the "none" approach. It's a= dded now. > * Sn 5.2.8.3: I think there is a problem with this way of specifying > the availability behaviour based on access priorities. In the complex > example in the last paragraph, it says that if A1 and A2 fail, the > traffic will be load-shared on A3 and A4. However, if only A1 fails, > the traffic would all be forced on to A2, right? This is unlikely to > be desirable - probably what the customer wants is to always be > load-sharing on 2 links, unless all of A1 - A4 fail (i.e., if only A1 > fails, then load-share on A2 and A3). There doesn't seem to be a way > to specify that using access priorities. > Having said that, this may not be a problem in practice: the SPs in > MEF all indicated that they never have more than 2 links to a given > site. > > [SLI] We have some use case with more than two connections. > The problem you describe is true but it's linked to the design chosen (so= customer has to adapt the capacity planning). > Most of the case I know are more multiple levels of backups, but the mode= l is flexible and can provide anykind of design, that's why we wanted to il= lustrate it. [DB1] I'm not sure I understand this. How would this model provide the design I = described? [SLI2] It does not. If A1 fails, traffic will go to A2, so A2 needs to have= sufficient capacity. > * Sn 5.2.8.3.1: If I understand correctly, the difference between > traffic protection enabled and disabled would be in how quickly the SP > can restore traffic towards a site if one of the network-access links > fails - is that correct? I'm not sure how useful this is without > putting some numbers in here - i.e. if the customer pays extra for > a service with traffic protection enabled, what traffic restoration > speed is the SP targeting or guaranteeing? > > [SLI] traffic protection is typically implementation of fast reroute tech= nology. > What SP is guaranteeing or not , is up to each SP ... [DB1] Yes of course, but the customer needs to know what it is. Maybe that's out= side the scope of the yang module? [SLI2] Yes it is outside. > Also, what is the expected behaviour if traffic protection is enabled > on one network-access link but disabled on another? Shouldn't it be > an attribute that applies to the site as a whole rather than to each > network-access link separately? > [SLI] We cannot really do it per site, due to the subVPN case where a sub= VPN site may have it and others not. > Agree that for multihoming, all logical access needs to have it. [DB1] Ok - so we still need to define what happens if one has it and another does= n't, right? [SLI2] Right, this subVPN case still bring some complexity unfortunately, maybe we= have to rethink again if we took the right approach. > I do not understand the site diversity constraint - how would a > path between 2 sites cross any other sites? Does it mean "are not > crossing the same P routers"? Or does it mean that the paths are > physically diverse? > [SLI] If you consider a path between two PEs, it will cross multiple netw= ork sites (where we host PEs or P routers). > For example, a path between NY and LA will maybe cross CHI, DEN and LV. > If we want another path with site diversity, we must avoid crossing CHI, = DEN and LV. [DB1] Ok, that makes sense - I was confused because everywhere else in the docume= nt, "site" means "customer site" but here it is being used with a different= meaning. Could we use a different word here? Would "PoP" work? [SLI2] I will find a new naming > > * Sn 8: What are the svc-input-bandwidth and svc-output-bandwidth? I > think the svc-output-bandwidth may be related to the QoS profile (see > earlier comments), but what is the svc-input-bandwidth for? > [SLI] It's used in case of asymmetric BW media like ADSL. > > * Sn 8: If MPLS is enabled (i.e. the CsC case), does the svc-mtu value > include the MPLS labels or just the IP packet? > > [SLI] it becomes MPLS BW because the service is no more IP. [DB1] Ok - can you clarify that in the text? [SLI2] Done ___________________________________________________________________________= ______________________________________________ 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 Thu Apr 28 04:42:34 2016 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 1E71912D683 for ; Thu, 28 Apr 2016 04:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 6RjkejSt80JM for ; Thu, 28 Apr 2016 04:42:30 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0F212D5BE for ; Thu, 28 Apr 2016 04:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18079; q=dns/txt; s=iport; t=1461843749; x=1463053349; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=sqs7vkCIkvdsf89rv8idfew4i5J1uQXV+YRQBEnWDXg=; b=F4i3psc2C/tAZ6As+d9UFX9M6bInbVD+MHJXBBWZlDS/jKaXcG8hc/X0 LV0xib/CvraixRIkrMdc7xLi7sUoOrbuqEq+ow10ApH8N13C/hW1gzmEL znRQ1jctqmCxrn7IeqfArSj3wzVmjc8nnSvzaceAn3ufWyTJDfOzcg5TK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBADd9SFX/xbLJq1VCYUIu3eGDwKBc?= =?us-ascii?q?AEBAQEBAWYnhEEBAQEDAScRQAYLCxgJFg8JAwIBAgFFBgEMBgIBARWICQjDAwE?= =?us-ascii?q?BAQEBAQEDAQEBAQEBAQEYhiGES4QWBE+FKgEEmBCIL0SFJIk6hVePMGKCBQUWg?= =?us-ascii?q?Uw7MId5gT0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,546,1454976000"; d="scan'208";a="637214654" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 11:42:26 +0000 Received: from [10.61.211.48] ([10.61.211.48]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3SBgQFf024685; Thu, 28 Apr 2016 11:42:26 GMT To: stephane.litkowski@orange.com, "l3sm@ietf.org" References: <5717AB01.90908@cisco.com> <9485_1461225367_57188797_9485_1886_9_9E32478DFA9976438E7A22F69B08FF921BB091AF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5718DD19.10505@cisco.com> <3217_1461252402_5718F132_3217_10280_3_9E32478DFA9976438E7A22F69B08FF921BB0A7FA@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: David Ball Message-ID: <5721F722.6040709@cisco.com> Date: Thu, 28 Apr 2016 12:42:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <3217_1461252402_5718F132_3217_10280_3_9E32478DFA9976438E7A22F69B08FF921BB0A7FA@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [L3sm] Feedback on L3SM draft X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 11:42:33 -0000 Hi Stephane, Apologies for the slow response, I have been at the MEF meeting this week and couldn't find a moment to look at this. Responses inline, I've stripped out the agreed parts. On 21/04/2016 16:26, stephane.litkowski@orange.com wrote: >> * Sn 5.1.1.4: Could you add an example of when hub-and-spoke-disjoint is >> used? Is it the same as having 2 hub-and-spoke VPNs where each hub >> site belongs to a different VPN and all the spoke sites belong to both >> VPNs? >> [SLI] Yes this is similar to the case you mention. > [DB1] > Is it similar or the same? What is the difference? > What I am asking about is the real-life case where you would need hub-and-spoke-disjoint. > [SLI2] From a service point of view, it's the same. From an implementation point of view, you can implement hub-spoke-disjoint in multiple ways. > I think there are very few use case (I remember at least one :) ), but this exist. [DB2] Yes agreed there are lots of ways to implement it; if it's the same from a service definition perspective then that would be useful to mention. >> For the subscriber to order a cloud service, they also need to know >> what actual service each Cloud ID is associated with - is that also >> assumed to be known by means outside this model? >> [SLI] Provider can communicate to customer the list of CloudIDs to be used. Is that an issue ? > [DB1] > Ok - no that's not an issue, although it would be useful to say explicitly in the draft that the association is provided to the customer by some other means. > [SLI2] I already updated the draft with a new paragraph regarding the external identifiers. [DB2] Great, thanks! >> * Sn 5.2.2.1.2: In the case of a site connected to multiple VPNs, how is >> traffic received from the site mapped to the right VPN? >> It is important to know which VPN the traffic maps to, not only to >> ensure it is sent to the right destination, but also because different >> VPNs might have different bandwidth or performance attributes. >> >> [SLI] No, attributes you are referring to are sites attributes, not VPN attributes. >> In multiVPN scenario, the same logical access is used to access to all VPNs : for instance, bandwidth is shared. > [DB1] > Sorry I was unclear; I was thinking of things like the bandwidth or latency transport constraints, which are per VPN. > [SLI2] In multiVPN case, in most of the case you have a multiVPN site that will take to different destination that are not part of the same multiVPN. > As an example, let's take site #1 which is multiVPN in VPN#A and #B. We have site#2 which is multiVPN #A and #C and site#3 which is multiVPN #B and #D. > If VPN#A express a transport constraint for site#1 <-> site#2, there is no ambiguity : for example, in VRF where site#1 is connected, there will be a TE tunnel to reach the PE connecting site#2 and BGP resolution will be done through this TE tunnel. [DB2] Right, there are no issues in this case. > There is a "technical complexity" where site#1 is multiVPN in A and B and site#2 is multiVPN in A and B also with different transport constraint expressed in VPN A and B between the two sites. [DB2] This is the case I'm asking about. > Honestly this does not really make sense IMO. But policy based routing (including source based) is necessary at ingress to map to the correct TE tunnel (only in case LAN is used to identity the VPN belonging). [DB2] If it really doesn't make sense, then I think it would be good to add a requirement to say that it MUST not be done. If it is allowed, then I think we need to say, from a service definition perspective, which VPN's constraints are applied; e.g. we could define some order for the VPNs and say that the first one that connects to the destination is used to apply the constraints. >> If so, is the implication that the destination address is looked up in >> each VPN? Is it possible that a route to the destination exists in >> multiple VPNs? How is the order of the VPNs in which to perform the >> lookups determined in that case? >> For instance, looking at the first example in Sn 5.2.2.2.2 (VPN >> policy), when a packet is received from VPN3_Site2 at PE6, how does >> PE6 determine whether to handle the packet as part of VPN2 or VPN3? >> [SLI] The IP destination is used. The destination IP can be part of VPN2 or VPN3. > [DB1] > Can the destination be part of VPN2 and VPN3? > If so, how does the PE determine which to use? > [SLI2] In L3VPN, it's a single route to reach the destination in both VPNs, so there is no need to choose. [DB2] Agreed, in implementation terms that is normally how it is done - it would be a single VRF. I was asking more from a service definition perspective. >> * Sn 5.2.2.1.3: Both from the perspective of what the management system >> needs to know to provision the SPs network, and from what needs to be >> agreed between the SP an the customer, this "Sub VPN attachment" case >> seems to be indistinguishable from treating it as separate sites. The >> text says: "It is similar than having separate sites instead that the >> customer wants to share some physical components while keeping strong >> isolation". However, from a service definition perspective, whether >> two separate sites happen to share the same physical infrastructure is >> immaterial, and in fact this could (or should) be invisible to the SP. >> I don't understand what additional value this "Sub VPN attachment" >> case provides. >> >> [SLI] This is a discussion we already had about how to model SubVPN. >> Considering them as separate sites was evaluated but there was some >> need to correlate sites that belongs the the same sub-VPN. This is particularly true when the SP provides the access. >> The SP needs to know that the IP sites must be built on the same access. > [DB1] > Would this be captured by them both refering to the same bearer (or to a bearer that ultimately maps to the same access)? > [SLI2] Yes [DB2] Ok - in that case it looks to me like the subVPN case isn't needed, i.e. you could model it as separate sites and infer from the fact they refer to the same bearer that they need to be correlated onto the same access. But I don't want to re-open old discussions; if there a consensus that subVPN is useful then that's ok. >> * Sn 5.2.3.1: In the case of a service-provider defined template, how >> would the customer be aware of what the template contains? Is it >> assumed to be made available by some mechanism outside the scope of >> this yang module? >> >> [SLI] The idea to have customer to create template, not really the provider. > [DB1] > The text says "a service provider defined template", so if that's not the intent then it probably needs to be updated. > In any case, the same question would exist the other way round: if the customer creates the template, how would the provider know what's in it? I guess this is the same as the cloud IDs and QoS profiles, it's some mechanism outside the scope of the yang, right? > > [SLI2] There is a misnaming here, it's bit a template (like site-template), it's a profile, like for cloud-access it requires external communication. [DB2] Ok. >> I don't think that is the intent; this situation is clearly intended >> to be in scope (especially as this is exactly the case described by >> the example in Sn 6); so I think either the definitions in Sn 2 or the >> scope statement in Sn 3 (or both) need to be modified. >> Note that this impacts several other parts of the document: e.g. 5.2.5 >> refers to a "CE-customer" boundary, 5.2.7.2 refers to a "CE to LAN >> connection", etc - neither of which makes sense given the current >> definitions in section 2. On the other hand, changing the definitions >> may also have other impacts, e.g. site diversity, acccess diversity, >> traffic protection, etc are described in terms of the CE-PE links, but >> for provider-managed sites perhaps they are intended to apply to the >> CE-customer links (or perhaps not)? >> [SLI] CE is located at customer premise whatever the management model. >> Site diversity ... always refers to CE-PE connection (customer site to provider network). > [DB1] > Ok - so in the provider-managed case, this is giving the customer visibility into the provider's network? > [SLI2] Why do you think that ? [DB2] If the CE is provider-managed, then logically the CE/PE links are part of the provider's network/responsibility, but the customer would still have visibility as to whether they terminate on different PEs or different PoPs. I think that's fine, it's just an interesting point to note. >> * (I) Sn 5.2.5: For information, MEF members indicated that several >> other protocols are in use that would need to be added to this list >> (in particular, ISIS and EIGRP). >> >> [SLI] IS-IS as PE-CE ? > [DB1] > Yes. > [SLI2] This requires a more global consensus I think ... [DB2] Sure - we can always add it as an augment if it turns out to be needed. >> * Sn 5.2.5.2: This seems to be describing a case where the SP-customer >> link could be a multipoint link; for example, where the SP provides a >> WiFi access point to a residential subscriber. Is that right? >> [SLI] Why multipoint ? > [DB1] > In this case, the wifi access point would be a provider-managed CE. The customer could have multiple devices that connect to the CE over wifi; so, the SP-customer link is a multipoint connection. > (Note the CE is provider-managed in this example, so the SP-customer link is not the PE-CE link; the PE-CE link might still be P2P). > [SLI2] Today we only manage P2P connection. [DB2] Ok. >> * (I) Sn 5.2.5.3: The use of VRRP should be invisible to the customer; >> so this is an example of something that does not need to be agreed >> between the SP and the customer, but which the management system in >> the SP needs to provision in the PEs. >> [SLI] VRRP case is a bit tricky. >> This is the case where customer has direct LAN connections multihomed to two PEs, so there are two logical accesses. > [DB1] > There are certainly 2 L2 links, but you could view it as a single L3 link (since the two PEs must also have L2 connectivity between them over the same LAN), and hence a single logical access. From the CE's perspective, it only sees a single L3 peer (just one who's corresponding MAC address keeps changing). Of course, from the provider's perspective, there are definitely 2 PEs... > [SLI2] When using VRRP, you have two layer 3 accesses and on top you will add the redundancy with a VIP. [DB2] Agreed, but it's a single LAN, right? >> * Sn 5.2.6.1.2: The rate-limit is described as "a percentage of the >> global service bandwidth" - is the "global service bandwidth" the >> value specified in the "svc-output-bandwidth" leaf? >> Similarly, the guaranteed-bw-percent is "expressed as a percentage", >> but it doesn't say what it is a percentage of. Is this also a >> percentage of the value in the "svc-output-bandwidth" leaf? >> [SLI] Yes it's a percentage of svc-output-bandwidth or input-bandwidth (depending if the access is symmetric in term of BW or not). >> I will add more text to precise it. > [DB1] > If it is egress policing only, wouldn't it always be the svc-output-bandwidth? When would svc-input-bandwidth be used? > [SLI2] If you think PE-CE, output-bw will be used on CE side (CE to PE), input will be used at PE side (PE to CE). [DB2] Ok, perhaps we are talking at cross purposes. By egress, I mean traffic from the provider towards the customer, and by ingress I mean traffic from the customer towards the provider. So I understood that it is egress policing only, i.e. meaning only from the provider towards the customer. Is that right? Similarly I thought "output" would be provider to customer and "input" would be customer to provider, but your description is the other way round. Probably we should define these terms more carefully if they are open to misinterpretation. >> * Sn 5.2.8.3: Similar question here: what is the expected behaviour if >> one access link is set to PE-diverse and one is set to PoP-diverse? > [DB1] > I think this case could be fixed by making this a per-site attribute rather than a per-network-access attribute. > [SLI2] We cannot remove diversity from site-network-access as it is required for multihoming. [DB2] I meant if you move it to be a per-site attribute, the same value would apply to all of the network accesses for the site. It doesn't need to be specified separately for each network access. >> Also is a "none" option needed, for when it's ok for both links to >> terminate at the same PE? >> [SLI] "None" option is when the container does not exist. Does it work ? In this case yes, both can terminate on the same PE. > [DB1] > Ah, ok - that definitely needs to be mentioned! > [SLI2] Thinking more about it, I finally prefer the "none" approach. It's added now. [DB2] Ok, thanks. >> * Sn 5.2.8.3: I think there is a problem with this way of specifying >> the availability behaviour based on access priorities. In the complex >> example in the last paragraph, it says that if A1 and A2 fail, the >> traffic will be load-shared on A3 and A4. However, if only A1 fails, >> the traffic would all be forced on to A2, right? This is unlikely to >> be desirable - probably what the customer wants is to always be >> load-sharing on 2 links, unless all of A1 - A4 fail (i.e., if only A1 >> fails, then load-share on A2 and A3). There doesn't seem to be a way >> to specify that using access priorities. >> Having said that, this may not be a problem in practice: the SPs in >> MEF all indicated that they never have more than 2 links to a given >> site. >> >> [SLI] We have some use case with more than two connections. >> The problem you describe is true but it's linked to the design chosen (so customer has to adapt the capacity planning). >> Most of the case I know are more multiple levels of backups, but the model is flexible and can provide anykind of design, that's why we wanted to illustrate it. > [DB1] > I'm not sure I understand this. How would this model provide the design I described? > [SLI2] It does not. If A1 fails, traffic will go to A2, so A2 needs to have sufficient capacity. [DB2] Ok - are there no cases with this type of design? I would think you would want a way to model this, e.g. specify the number of links that should be active. >> * Sn 5.2.8.3.1: If I understand correctly, the difference between >> traffic protection enabled and disabled would be in how quickly the SP >> can restore traffic towards a site if one of the network-access links >> fails - is that correct? I'm not sure how useful this is without >> putting some numbers in here - i.e. if the customer pays extra for >> a service with traffic protection enabled, what traffic restoration >> speed is the SP targeting or guaranteeing? >> >> [SLI] traffic protection is typically implementation of fast reroute technology. >> What SP is guaranteeing or not , is up to each SP ... > [DB1] > Yes of course, but the customer needs to know what it is. Maybe that's outside the scope of the yang module? > [SLI2] Yes it is outside. [DB2] Ok, could you add some text to clarify that? >> Also, what is the expected behaviour if traffic protection is enabled >> on one network-access link but disabled on another? Shouldn't it be >> an attribute that applies to the site as a whole rather than to each >> network-access link separately? >> [SLI] We cannot really do it per site, due to the subVPN case where a subVPN site may have it and others not. >> Agree that for multihoming, all logical access needs to have it. > [DB1] > Ok - so we still need to define what happens if one has it and another doesn't, right? > [SLI2] > Right, this subVPN case still bring some complexity unfortunately, maybe we have to rethink again if we took the right approach. [DB2] I will leave it to you and the other people involved in that discussion to decide whether to re-open it; as I said, I don't see the need for the subVPN case but I don't want to disrupt the consensus. >> I do not understand the site diversity constraint - how would a >> path between 2 sites cross any other sites? Does it mean "are not >> crossing the same P routers"? Or does it mean that the paths are >> physically diverse? >> [SLI] If you consider a path between two PEs, it will cross multiple network sites (where we host PEs or P routers). >> For example, a path between NY and LA will maybe cross CHI, DEN and LV. >> If we want another path with site diversity, we must avoid crossing CHI, DEN and LV. > [DB1] > Ok, that makes sense - I was confused because everywhere else in the document, "site" means "customer site" but here it is being used with a different meaning. Could we use a different word here? Would "PoP" work? > [SLI2] I will find a new naming [DB2] Ok, thanks. >> * Sn 8: What are the svc-input-bandwidth and svc-output-bandwidth? I >> think the svc-output-bandwidth may be related to the QoS profile (see >> earlier comments), but what is the svc-input-bandwidth for? >> [SLI] It's used in case of asymmetric BW media like ADSL. [DB2] Right, but what behaviour is implied or required if a particular value is specified? I think a bit more explanation would help readers understand how to use these values. David -- David Ball From nobody Fri Apr 29 01:38:30 2016 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 A6EBF12D59D for ; Fri, 29 Apr 2016 01:38:28 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Ahg91kfo3rrw for ; Fri, 29 Apr 2016 01:38:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5D712D579 for ; Fri, 29 Apr 2016 01:38:25 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9B9F122D771; Fri, 29 Apr 2016 10:38:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 737D6238059; Fri, 29 Apr 2016 10:38:24 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0279.002; Fri, 29 Apr 2016 10:38:24 +0200 From: To: David Ball , "l3sm@ietf.org" Thread-Topic: [L3sm] Feedback on L3SM draft Thread-Index: AQHRmx/OuCnEXvw7QESYANDcSs89x5+T8EpQgABkY4CAACMs4IAKtnIAgAF9oaA= Date: Fri, 29 Apr 2016 08:38:23 +0000 Message-ID: <21410_1461919104_57231D80_21410_2745_2_9E32478DFA9976438E7A22F69B08FF921BB15D4E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <5717AB01.90908@cisco.com> <9485_1461225367_57188797_9485_1886_9_9E32478DFA9976438E7A22F69B08FF921BB091AF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5718DD19.10505@cisco.com> <3217_1461252402_5718F132_3217_10280_3_9E32478DFA9976438E7A22F69B08FF921BB0A7FA@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5721F722.6040709@cisco.com> In-Reply-To: <5721F722.6040709@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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.29.72416 Archived-At: Subject: Re: [L3sm] Feedback on L3SM draft X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 29 Apr 2016 08:38:28 -0000 More inline -----Original Message----- From: David Ball [mailto:daviball@cisco.com]=20 Sent: Thursday, April 28, 2016 13:42 To: LITKOWSKI Stephane OBS/OINIS; l3sm@ietf.org Subject: Re: [L3sm] Feedback on L3SM draft >> * Sn 5.2.2.1.3: Both from the perspective of what the management system >> needs to know to provision the SPs network, and from what needs to = be >> agreed between the SP an the customer, this "Sub VPN attachment" ca= se >> seems to be indistinguishable from treating it as separate sites. = The >> text says: "It is similar than having separate sites instead that t= he >> customer wants to share some physical components while keeping stro= ng >> isolation". However, from a service definition perspective, whether >> two separate sites happen to share the same physical infrastructure= is >> immaterial, and in fact this could (or should) be invisible to the = SP. >> I don't understand what additional value this "Sub VPN attachment" >> case provides. >> >> [SLI] This is a discussion we already had about how to model SubVPN. >> Considering them as separate sites was evaluated but there was some=20 >> need to correlate sites that belongs the the same sub-VPN. This is parti= cularly true when the SP provides the access. >> The SP needs to know that the IP sites must be built on the same access. > [DB1] > Would this be captured by them both refering to the same bearer (or to a = bearer that ultimately maps to the same access)? > [SLI2] Yes [DB2] Ok - in that case it looks to me like the subVPN case isn't needed, i.e.=20 you could model it as separate sites and infer from the fact they refer to = the same bearer that they need to be correlated onto the same access. But = I don't want to re-open old discussions; if there a consensus that subVPN i= s useful then that's ok. [SLI] I have still some concern on the current modeling of subVPN. subVPN i= s needed for sure, there are plenty of usage in real world, now the questio= n is how to model it. I think we can reopen the discussion. >> I don't think that is the intent; this situation is clearly intended >> to be in scope (especially as this is exactly the case described by >> the example in Sn 6); so I think either the definitions in Sn 2 or = the >> scope statement in Sn 3 (or both) need to be modified. >> Note that this impacts several other parts of the document: e.g. 5.= 2.5 >> refers to a "CE-customer" boundary, 5.2.7.2 refers to a "CE to LAN >> connection", etc - neither of which makes sense given the current >> definitions in section 2. On the other hand, changing the definiti= ons >> may also have other impacts, e.g. site diversity, acccess diversity, >> traffic protection, etc are described in terms of the CE-PE links, = but >> for provider-managed sites perhaps they are intended to apply to the >> CE-customer links (or perhaps not)? >> [SLI] CE is located at customer premise whatever the management model. >> Site diversity ... always refers to CE-PE connection (customer site to p= rovider network). > [DB1] > Ok - so in the provider-managed case, this is giving the customer visibil= ity into the provider's network? > [SLI2] Why do you think that ? [DB2] If the CE is provider-managed, then logically the CE/PE links are par= t of the provider's network/responsibility, but the customer would still ha= ve visibility as to whether they terminate on different PEs or different Po= Ps. I think that's fine, it's just an interesting point to note. [SLI] Ok >> * (I) Sn 5.2.5: For information, MEF members indicated that several >> other protocols are in use that would need to be added to this list >> (in particular, ISIS and EIGRP). >> >> [SLI] IS-IS as PE-CE ? > [DB1] > Yes. > [SLI2] This requires a more global consensus I think ... [DB2] Sure - we can always add it as an augment if it turns out to be needed. [SLI] I would prefer augmentation for this one. >> * (I) Sn 5.2.5.3: The use of VRRP should be invisible to the customer; >> so this is an example of something that does not need to be agreed >> between the SP and the customer, but which the management system in >> the SP needs to provision in the PEs. >> [SLI] VRRP case is a bit tricky. >> This is the case where customer has direct LAN connections multihomed to= two PEs, so there are two logical accesses. > [DB1] > There are certainly 2 L2 links, but you could view it as a single L3 link= (since the two PEs must also have L2 connectivity between them over the sa= me LAN), and hence a single logical access. From the CE's perspective, it = only sees a single L3 peer (just one who's corresponding MAC address keeps = changing). Of course, from the provider's perspective, there are definitel= y 2 PEs... > [SLI2] When using VRRP, you have two layer 3 accesses and on top you will= add the redundancy with a VIP. [DB2] Agreed, but it's a single LAN, right? [SLI] Right , single LAN >> * Sn 5.2.6.1.2: The rate-limit is described as "a percentage of the >> global service bandwidth" - is the "global service bandwidth" the >> value specified in the "svc-output-bandwidth" leaf? >> Similarly, the guaranteed-bw-percent is "expressed as a percentage", >> but it doesn't say what it is a percentage of. Is this also a >> percentage of the value in the "svc-output-bandwidth" leaf? >> [SLI] Yes it's a percentage of svc-output-bandwidth or input-bandwidth (= depending if the access is symmetric in term of BW or not). >> I will add more text to precise it. > [DB1] > If it is egress policing only, wouldn't it always be the svc-output-bandw= idth? When would svc-input-bandwidth be used? > [SLI2] If you think PE-CE, output-bw will be used on CE side (CE to PE), = input will be used at PE side (PE to CE). [DB2] Ok, perhaps we are talking at cross purposes. By egress, I mean traffic from the provider towards the customer, and by in= gress I mean traffic from the customer towards the provider. So I understo= od that it is egress policing only, i.e. meaning only from the provider tow= ards the customer. Is that right? Similarly I thought "output" would be provider to customer and "input"=20 would be customer to provider, but your description is the other way round. Probably we should define these terms more carefully if they are open to mi= sinterpretation. [SLI] I fixed the text to clearly describe it. >> * Sn 5.2.8.3: Similar question here: what is the expected behaviour if >> one access link is set to PE-diverse and one is set to PoP-diverse? > [DB1] > I think this case could be fixed by making this a per-site attribute rath= er than a per-network-access attribute. > [SLI2] We cannot remove diversity from site-network-access as it is requi= red for multihoming. [DB2] I meant if you move it to be a per-site attribute, the same value wou= ld apply to all of the network accesses for the site. It doesn't need to b= e specified separately for each network access. >> * Sn 5.2.8.3.1: If I understand correctly, the difference between >> traffic protection enabled and disabled would be in how quickly the= SP >> can restore traffic towards a site if one of the network-access lin= ks >> fails - is that correct? I'm not sure how useful this is without >> putting some numbers in here - i.e. if the customer pays extra for >> a service with traffic protection enabled, what traffic restoration >> speed is the SP targeting or guaranteeing? >> >> [SLI] traffic protection is typically implementation of fast reroute tec= hnology. >> What SP is guaranteeing or not , is up to each SP ... > [DB1] > Yes of course, but the customer needs to know what it is. Maybe that's o= utside the scope of the yang module? > [SLI2] Yes it is outside. [DB2] Ok, could you add some text to clarify that? [SLI] Ok will add some >> Also, what is the expected behaviour if traffic protection is enabl= ed >> on one network-access link but disabled on another? Shouldn't it be >> an attribute that applies to the site as a whole rather than to each >> network-access link separately? >> [SLI] We cannot really do it per site, due to the subVPN case where a su= bVPN site may have it and others not. >> Agree that for multihoming, all logical access needs to have it. > [DB1] > Ok - so we still need to define what happens if one has it and another do= esn't, right? > [SLI2] > Right, this subVPN case still bring some complexity unfortunately, maybe = we have to rethink again if we took the right approach. [DB2] I will leave it to you and the other people involved in that discussion to = decide whether to re-open it; as I said, I don't see the need for the subVP= N case but I don't want to disrupt the consensus. [SLI] As pointed, I'm open to reevaluate how subVPN is modeled. >> * Sn 8: What are the svc-input-bandwidth and svc-output-bandwidth? I >> think the svc-output-bandwidth may be related to the QoS profile (s= ee >> earlier comments), but what is the svc-input-bandwidth for? >> [SLI] It's used in case of asymmetric BW media like ADSL. [DB2] Right, but what behaviour is implied or required if a particular value is s= pecified? I think a bit more explanation would help readers understand how= to use these values. [SLI] I added more text to explain how it should be used. David -- David Ball ___________________________________________________________________________= ______________________________________________ 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 Fri Apr 29 04:59:18 2016 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 54F9B12D1E9 for ; Fri, 29 Apr 2016 04:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 r8_FjvQMif24 for ; Fri, 29 Apr 2016 04:59:10 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12EF612D12F for ; Fri, 29 Apr 2016 04:59:10 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 2F190C0DA6 for ; Fri, 29 Apr 2016 13:59:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 0417E20068 for ; Fri, 29 Apr 2016 13:59:08 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0279.002; Fri, 29 Apr 2016 13:59:07 +0200 From: To: "l3sm@ietf.org" Thread-Topic: Modeling subVPN Thread-Index: AdGiDPRsataXjvhJTvmhgK7WIQu81Q== Date: Fri, 29 Apr 2016 11:59:06 +0000 Message-ID: <30431_1461931148_57234C8C_30431_1247_1_9E32478DFA9976438E7A22F69B08FF921BB16586@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921BB16586OPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [L3sm] Modeling subVPN X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 29 Apr 2016 11:59:17 -0000 --_004_9E32478DFA9976438E7A22F69B08FF921BB16586OPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921BB16586OPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF921BB16586OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I still have some concern about the current modeling of subVPN that reuses = the site-network-access that was defined for multihoming. Mixing both notions brings IMO confusion while a subVPN is just a regular s= ite that reuses a particular existing physical infrastructure. I would so propose to rediscuss the point. My proposal to discuss would be to use regular sites to model subVPN using = the following tweak : We add a new site property which tells what kind of site it is : - "Regular" : standard site without subVPN - "SubVPN-physical" : physical site that will support subVPN. This= kind of site will have a very limited config, as most properties will be o= n the subVPN sites. - "SubVPN-virtual" : define properties of each subVPN slice, it ne= eds a reference to the attached "subVPN-physical" With this, we keep the site-network-access just for multihoming properties. Thoughts ? [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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. --_000_9E32478DFA9976438E7A22F69B08FF921BB16586OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I still have some concern about the current modeling= of subVPN that reuses the site-network-access that was defined for multiho= ming.

Mixing both notions brings IMO confusion while a sub= VPN is just a regular site that reuses a particular existing physical infra= structure.

 

I would so propose to rediscuss the point.

 

My proposal to discuss would be to use regular sites= to model subVPN using the following tweak :

We add a new site property which tells what kind of = site it is :

-     &= nbsp;    “Regular” : standard site without subVP= N

-     &= nbsp;    “SubVPN-physical” : physical site that = will support subVPN. This kind of site will have a very limited config, as = most properties will be on the subVPN sites.

-     &= nbsp;    “SubVPN-virtual” : define properties of= each subVPN slice, it needs a reference to the attached “subVPN-phys= ical”

With this, we keep the site-network-access just for = multihoming properties.

 

Thoughts ?

 

 

3D"O=

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
s= tephane.litkowski@orange.com

 

______________________________________________________________________=
___________________________________________________

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.
--_000_9E32478DFA9976438E7A22F69B08FF921BB16586OPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF921BB16586OPEXCLILMA4corp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1093; creation-date="Fri, 29 Apr 2016 11:59:06 GMT"; modification-date="Fri, 29 Apr 2016 11:59:06 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1O48f afbXMsDWl0WjcoSAuDg49aj/AOFiad/z53f5L/jXB6r/AMhe9/67v/M1Ur5Geb4pSaTX3H2dPJcJ KCbT+89H/wCFiad/z53f5L/jR/wsTTv+fO7/ACX/ABrziip/tnFd19xX9iYPs/vPR/8AhYmnf8+d 3+S/40V5xRR/bOK7r7g/sTB9n95b1X/kL3v/AF3f+ZqpW3Po17qGo3s0Cx7DdPGpeQLvbOdq56mo R4d1EmEFYVaZdyI0oDY9cda450KspNqLO2niKUYJOSvbv5GVRWwPC+qmR4zFErI/l4aUDc2A2B68 GmDw7qTQrIIkJZVYR+YN+GOAdvuan6tW/lf3FfWqH86+8yqK2bjQG0+EvqU/2dmyIgieYGI6gkHg 0VM6M4O0tGVCtCavF3R1o8Oa7BcTtbXdh5TztPGJYyxjY9xxwcUxfDniNZ1m+32DOIPs+WjJymc8 8dc96KK+y/s+l3f3s+J/tKt2X3Ie+geJZJlla/0/eswmH7s/eChfT0FXDo2rDTRCktoLoIqfaCxy NrZGPlz+GaKKpYGmr6vXzJlj6sraLTyMrUPCOuant+03lh8pJ+RGXJPUniiiisZ5Thpvmldv1N4Z xioLljZL0R//2Q== --_004_9E32478DFA9976438E7A22F69B08FF921BB16586OPEXCLILMA4corp_-- From nobody Fri Apr 29 07:48:03 2016 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 4C3E512D0B5 for ; Fri, 29 Apr 2016 07:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 XEZZ3U8trZjS for ; Fri, 29 Apr 2016 07:47:59 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A5D12B03A for ; Fri, 29 Apr 2016 07:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11152; q=dns/txt; s=iport; t=1461941278; x=1463150878; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=YBARGS4ajeHz3gFa2uvEh408GB2u2v0d4gSTiFEJTEM=; b=XMepBQ8Sa9NdU9zfj3pgoGgwhPEUomF+Vevozy+S3HJD/okPPon7xZxC slZ2VlHl+gchsCE9tcuSwDdClcQq8IRfkzG50HhgCYWm4lX17hirPryAb Jl9UUR0SODMZyolrRDxOe2VPXxOiVosjq3DhAQ88ggHekSZ9mYC50banf s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBAAIcyNX/xbLJq1dhAt9u3UXC4VuA?= =?us-ascii?q?oF2AQEBAQEBZieEQQEBAQQBAQE1NgoNBAsRBAEBAQkWCAcJAwIBAgEVHwkIBgE?= =?us-ascii?q?MBgIBAYgmDsQuAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIYRMhA8LBgFIhSoBB?= =?us-ascii?q?JgTjheBZ4RNgwaFV4YkiQxiggUFFoFMOzCHRAgXgR4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208";a="637234264" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 14:47:55 +0000 Received: from [10.63.23.142] (dhcp-ensft1-uk-vla370-10-63-23-142.cisco.com [10.63.23.142]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3TElt1q032163; Fri, 29 Apr 2016 14:47:55 GMT To: stephane.litkowski@orange.com, "l3sm@ietf.org" References: <5717AB01.90908@cisco.com> <9485_1461225367_57188797_9485_1886_9_9E32478DFA9976438E7A22F69B08FF921BB091AF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5718DD19.10505@cisco.com> <3217_1461252402_5718F132_3217_10280_3_9E32478DFA9976438E7A22F69B08FF921BB0A7FA@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <5721F722.6040709@cisco.com> <21410_1461919104_57231D80_21410_2745_2_9E32478DFA9976438E7A22F69B08FF921BB15D4E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: David Ball Message-ID: <5723741B.4070807@cisco.com> Date: Fri, 29 Apr 2016 15:47:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <21410_1461919104_57231D80_21410_2745_2_9E32478DFA9976438E7A22F69B08FF921BB15D4E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [L3sm] Feedback on L3SM draft X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 29 Apr 2016 14:48:01 -0000 Thanks Stephane. Will you be publishing a new update to the draft with the new text? David On 29/04/2016 09:38, stephane.litkowski@orange.com wrote: > More inline > > -----Original Message----- > From: David Ball [mailto:daviball@cisco.com] > Sent: Thursday, April 28, 2016 13:42 > To: LITKOWSKI Stephane OBS/OINIS; l3sm@ietf.org > Subject: Re: [L3sm] Feedback on L3SM draft > > > > >>> * Sn 5.2.2.1.3: Both from the perspective of what the management system >>> needs to know to provision the SPs network, and from what needs to be >>> agreed between the SP an the customer, this "Sub VPN attachment" case >>> seems to be indistinguishable from treating it as separate sites. The >>> text says: "It is similar than having separate sites instead that the >>> customer wants to share some physical components while keeping strong >>> isolation". However, from a service definition perspective, whether >>> two separate sites happen to share the same physical infrastructure is >>> immaterial, and in fact this could (or should) be invisible to the SP. >>> I don't understand what additional value this "Sub VPN attachment" >>> case provides. >>> >>> [SLI] This is a discussion we already had about how to model SubVPN. >>> Considering them as separate sites was evaluated but there was some >>> need to correlate sites that belongs the the same sub-VPN. This is particularly true when the SP provides the access. >>> The SP needs to know that the IP sites must be built on the same access. >> [DB1] >> Would this be captured by them both refering to the same bearer (or to a bearer that ultimately maps to the same access)? >> [SLI2] Yes > [DB2] > Ok - in that case it looks to me like the subVPN case isn't needed, i.e. > you could model it as separate sites and infer from the fact they refer to the same bearer that they need to be correlated onto the same access. But I don't want to re-open old discussions; if there a consensus that subVPN is useful then that's ok. > > [SLI] I have still some concern on the current modeling of subVPN. subVPN is needed for sure, there are plenty of usage in real world, now the question is how to model it. I think we can reopen the discussion. > >>> I don't think that is the intent; this situation is clearly intended >>> to be in scope (especially as this is exactly the case described by >>> the example in Sn 6); so I think either the definitions in Sn 2 or the >>> scope statement in Sn 3 (or both) need to be modified. >>> Note that this impacts several other parts of the document: e.g. 5.2.5 >>> refers to a "CE-customer" boundary, 5.2.7.2 refers to a "CE to LAN >>> connection", etc - neither of which makes sense given the current >>> definitions in section 2. On the other hand, changing the definitions >>> may also have other impacts, e.g. site diversity, acccess diversity, >>> traffic protection, etc are described in terms of the CE-PE links, but >>> for provider-managed sites perhaps they are intended to apply to the >>> CE-customer links (or perhaps not)? >>> [SLI] CE is located at customer premise whatever the management model. >>> Site diversity ... always refers to CE-PE connection (customer site to provider network). >> [DB1] >> Ok - so in the provider-managed case, this is giving the customer visibility into the provider's network? >> [SLI2] Why do you think that ? > [DB2] If the CE is provider-managed, then logically the CE/PE links are part of the provider's network/responsibility, but the customer would still have visibility as to whether they terminate on different PEs or different PoPs. I think that's fine, it's just an interesting point to note. > [SLI] Ok > >>> * (I) Sn 5.2.5: For information, MEF members indicated that several >>> other protocols are in use that would need to be added to this list >>> (in particular, ISIS and EIGRP). >>> >>> [SLI] IS-IS as PE-CE ? >> [DB1] >> Yes. >> [SLI2] This requires a more global consensus I think ... > [DB2] > Sure - we can always add it as an augment if it turns out to be needed. > > [SLI] I would prefer augmentation for this one. > > > >>> * (I) Sn 5.2.5.3: The use of VRRP should be invisible to the customer; >>> so this is an example of something that does not need to be agreed >>> between the SP and the customer, but which the management system in >>> the SP needs to provision in the PEs. >>> [SLI] VRRP case is a bit tricky. >>> This is the case where customer has direct LAN connections multihomed to two PEs, so there are two logical accesses. >> [DB1] >> There are certainly 2 L2 links, but you could view it as a single L3 link (since the two PEs must also have L2 connectivity between them over the same LAN), and hence a single logical access. From the CE's perspective, it only sees a single L3 peer (just one who's corresponding MAC address keeps changing). Of course, from the provider's perspective, there are definitely 2 PEs... >> [SLI2] When using VRRP, you have two layer 3 accesses and on top you will add the redundancy with a VIP. > [DB2] > Agreed, but it's a single LAN, right? > [SLI] Right , single LAN > > >>> * Sn 5.2.6.1.2: The rate-limit is described as "a percentage of the >>> global service bandwidth" - is the "global service bandwidth" the >>> value specified in the "svc-output-bandwidth" leaf? >>> Similarly, the guaranteed-bw-percent is "expressed as a percentage", >>> but it doesn't say what it is a percentage of. Is this also a >>> percentage of the value in the "svc-output-bandwidth" leaf? >>> [SLI] Yes it's a percentage of svc-output-bandwidth or input-bandwidth (depending if the access is symmetric in term of BW or not). >>> I will add more text to precise it. >> [DB1] >> If it is egress policing only, wouldn't it always be the svc-output-bandwidth? When would svc-input-bandwidth be used? >> [SLI2] If you think PE-CE, output-bw will be used on CE side (CE to PE), input will be used at PE side (PE to CE). > [DB2] > Ok, perhaps we are talking at cross purposes. > By egress, I mean traffic from the provider towards the customer, and by ingress I mean traffic from the customer towards the provider. So I understood that it is egress policing only, i.e. meaning only from the provider towards the customer. Is that right? > Similarly I thought "output" would be provider to customer and "input" > would be customer to provider, but your description is the other way round. > Probably we should define these terms more carefully if they are open to misinterpretation. > [SLI] I fixed the text to clearly describe it. > > >>> * Sn 5.2.8.3: Similar question here: what is the expected behaviour if >>> one access link is set to PE-diverse and one is set to PoP-diverse? >> [DB1] >> I think this case could be fixed by making this a per-site attribute rather than a per-network-access attribute. >> [SLI2] We cannot remove diversity from site-network-access as it is required for multihoming. > [DB2] I meant if you move it to be a per-site attribute, the same value would apply to all of the network accesses for the site. It doesn't need to be specified separately for each network access. > > > >>> * Sn 5.2.8.3.1: If I understand correctly, the difference between >>> traffic protection enabled and disabled would be in how quickly the SP >>> can restore traffic towards a site if one of the network-access links >>> fails - is that correct? I'm not sure how useful this is without >>> putting some numbers in here - i.e. if the customer pays extra for >>> a service with traffic protection enabled, what traffic restoration >>> speed is the SP targeting or guaranteeing? >>> >>> [SLI] traffic protection is typically implementation of fast reroute technology. >>> What SP is guaranteeing or not , is up to each SP ... >> [DB1] >> Yes of course, but the customer needs to know what it is. Maybe that's outside the scope of the yang module? >> [SLI2] Yes it is outside. > [DB2] > Ok, could you add some text to clarify that? > [SLI] Ok will add some > >>> Also, what is the expected behaviour if traffic protection is enabled >>> on one network-access link but disabled on another? Shouldn't it be >>> an attribute that applies to the site as a whole rather than to each >>> network-access link separately? >>> [SLI] We cannot really do it per site, due to the subVPN case where a subVPN site may have it and others not. >>> Agree that for multihoming, all logical access needs to have it. >> [DB1] >> Ok - so we still need to define what happens if one has it and another doesn't, right? >> [SLI2] >> Right, this subVPN case still bring some complexity unfortunately, maybe we have to rethink again if we took the right approach. > [DB2] > I will leave it to you and the other people involved in that discussion to decide whether to re-open it; as I said, I don't see the need for the subVPN case but I don't want to disrupt the consensus. > [SLI] As pointed, I'm open to reevaluate how subVPN is modeled. > > >>> * Sn 8: What are the svc-input-bandwidth and svc-output-bandwidth? I >>> think the svc-output-bandwidth may be related to the QoS profile (see >>> earlier comments), but what is the svc-input-bandwidth for? >>> [SLI] It's used in case of asymmetric BW media like ADSL. > [DB2] > Right, but what behaviour is implied or required if a particular value is specified? I think a bit more explanation would help readers understand how to use these values. > [SLI] > I added more text to explain how it should be used. > > > > David > > -- > David Ball > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm -- David Ball From nobody Fri Apr 29 19:26:15 2016 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 D274B12D553 for ; Fri, 29 Apr 2016 19:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, 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 knjflFMBGBPU for ; Fri, 29 Apr 2016 19:26:11 -0700 (PDT) Received: from post-send.kddi.com (athena2.kddi.com [27.90.165.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1C20E12D127 for ; Fri, 29 Apr 2016 19:26:11 -0700 (PDT) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id 2584FE0037; Sat, 30 Apr 2016 11:26:10 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Sat, 30 Apr 2016 11:26:10 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id E8C814C0058; Sat, 30 Apr 2016 11:26:09 +0900 (JST) Received: from LTMC2153.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id DD7DC4C0051; Sat, 30 Apr 2016 11:26:09 +0900 (JST) Received: from LTMC2153.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2153.kddi.com with ESMTP id u3U2Q9cZ009690; Sat, 30 Apr 2016 11:26:09 +0900 Received: from LTMC2153.kddi.com.mid_64149674 (localhost.localdomain [127.0.0.1]) by LTMC2153.kddi.com with ESMTP id u3U2G4uU007603; Sat, 30 Apr 2016 11:16:05 +0900 X-SA-MID: 64149674 Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Sat, 30 Apr 2016 11:16:04 +0900 From: "Ogaki, Kenichi" To: , References: <30431_1461931148_57234C8C_30431_1247_1_9E32478DFA9976438E7A22F69B08FF921BB16586@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <30431_1461931148_57234C8C_30431_1247_1_9E32478DFA9976438E7A22F69B08FF921BB16586@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Date: Sat, 30 Apr 2016 11:16:04 +0900 Message-ID: <043001d1a286$3f87d940$be978bc0$@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: AQH8CzroV5BchRcawZ0655pvD+BCc59M9TnQ Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Modeling subVPN X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 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, 30 Apr 2016 02:26:14 -0000 Hi Stephane, IMO, it's not good idea to re-open the old discussion. I think the current model is more universal and simpler. In principle, increase of the number of parameters causes the complexity of the system development. In your proposal, Regular site is a subset of a SubVPN site, with one site-network-access to a single (or multi) VPN. The problem is to allow two options for one usecase. A customer may have no plan whether she/he would use any subVPN or not later, when she/he creates a new site with one site-network-access. In this case, the customer should always choose a SubVPN site, because it must bring some troubles to change a Regular site to a SubVPN site for customers as well as operators. Keeping the existing site-network-access without any disruption, the customer must request to change the site property from Regular to SubVPN and move the access to under SubVPN-virtual, and the operator does so. I don't want to develop a function to support such specific scenario on our management system. This means operators who are offering subVPN service will not use Regular site. We all know one size doesn't fit all, but we shouldn't optimize the model for each specific usecase and must keep it simple. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com Sent: Friday, April 29, 2016 8:59 PM To: l3sm@ietf.org Subject: [L3sm] Modeling subVPN Hi, I still have some concern about the current modeling of subVPN that reuses the site-network-access that was defined for multihoming. Mixing both notions brings IMO confusion while a subVPN is just a regular site that reuses a particular existing physical infrastructure. I would so propose to rediscuss the point. My proposal to discuss would be to use regular sites to model subVPN using the following tweak : We add a new site property which tells what kind of site it is : - "Regular" : standard site without subVPN - "SubVPN-physical" : physical site that will support subVPN. This kind of site will have a very limited config, as most properties will be on the subVPN sites. - "SubVPN-virtual" : define properties of each subVPN slice, it needs a reference to the attached "subVPN-physical" With this, we keep the site-network-access just for multihoming properties. Thoughts ? Orange logo Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.