From nobody Mon Jul 3 02:45:51 2017 Return-Path: X-Original-To: l2sm@ietf.org Delivered-To: l2sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 320CF131565; Mon, 3 Jul 2017 02:45:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: l2sm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149907514916.4930.9753967705309444500@ietfa.amsl.com> Date: Mon, 03 Jul 2017 02:45:49 -0700 Archived-At: Subject: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-02.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:45:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the L2VPN Service Model of the IETF. Title : A YANG Data Model for L2VPN Service Delivery Authors : Bin Wen Giuseppe Fioccola Chongfeng Xie Luay Jalil Filename : draft-ietf-l2sm-l2vpn-service-model-02.txt Pages : 160 Date : 2017-07-03 Abstract: This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The data model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-02 https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-l2sm-l2vpn-service-model-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 02:52:46 2017 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3298F12EC18; Mon, 3 Jul 2017 02:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXwb5cp4T3t0; Mon, 3 Jul 2017 02:52:38 -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 9438F1289C3; Mon, 3 Jul 2017 02:52:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJQ32271; Mon, 03 Jul 2017 09:52:35 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 3 Jul 2017 10:52:06 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 3 Jul 2017 17:52:01 +0800 From: Qin Wu To: "l3sm@ietf.org" , "l2sm@ietf.org" CC: "adrian@olddog.co.uk" , "Benoit Claise (bclaise)" Thread-Topic: Followup of RFC8049bis Thread-Index: AdLz4gQczWlV+rrbRBePS8Ez8xfWvQ== Date: Mon, 3 Jul 2017 09:52:00 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A9956B2nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.595A13E3.00F6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4f3feb204b41f273a8b540d91adafc40 Archived-At: Subject: [L2sm] Followup of RFC8049bis X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:52:40 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9A9956B2nkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, All: The v-(02) of RFC8049bis has just been posted, https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ thanks Jan and David for valuable comments and input, the main changes incl= ude: 1.Specify what type of IPv6 address in the model for IPv6 connection? link-= local global 2.Specify provider address and a list of start-end addresses from provider = address 3.remove redundant parameters such as deny-any-except and permit-any-except= under cloud-access? 4. Add a few text to clarify what the site is in section 6.3 5. Add a few text to clarify why having customer-name. 6. Fixed two typos pointed by Jan recently. Talking with L3Sm design team, we believe how information is communicated b= y SP to the customer is beyond the scope of RFC8049 has already been clarified in section 6.6, 2nd paragraph, section 6= .6.3,2nd paragraph, 1st bullet, 3rd bullet, section 6.12.2.2,4th paragraph. Regarding whether AS number under BGP protocol is supposed to be the custom= er's AS number or the SP's AS number, we think AS number as part of BGP protocol related parameters are applied to provider to customer= boundary, therefore the answer is depending on how the management model is administered. As Jan pointed out, we still have some new mandatory fields introduced in v= -(02) haven't been reflected in the examples. But he is okay with the curre= nt shape. Please review these changes, let us know if there is any additional comment= s. Regards! Qin (on behalf of team) --_000_B8F9A780D330094D99AF023C5877DABA9A9956B2nkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, All:

The v-(02) of RFC8049bis has ju= st been posted,

https://datatracker.ietf.org/doc= /draft-wu-l3sm-rfc8049bis/

thanks Jan and David for valuab= le comments and input, the main changes include:

1.Specify what type of IPv6 address in the model for IPv6 connec= tion? link-local global

2.Specify provider address and a list of start-end addresses fro= m provider address

3.remove redundant parameters such as deny-any-except and permit= -any-except under cloud-access?

4. Add a few text to clarify wh= at the site is in section 6.3

5. Add a few text to clarify wh= y having customer-name.

6. Fixed two typos pointed by J= an recently.

 

Talking with L3Sm design team, = we believe how information is communicated by SP to the customer is beyond = the scope of

RFC8049 has already been clarified in section 6.6, 2nd= paragraph, section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section 6.= 12.2.2,4th paragraph.

 

Regarding whether AS number und= er BGP protocol is supposed to be the customer's AS number or the SP's AS n= umber, we think AS number as

part of BGP protocol related pa= rameters are applied to provider to customer boundary, therefore the answer= is depending on

how the management model is administered.

 

As Jan pointed out, we still have some new mandatory f= ields introduced in v-(02) haven’t been reflected in the examples. Bu= t he is okay with the current shape.

Please review these changes, let us know if there is a= ny additional comments.

 

Regards!

Qin (on behalf of team)

 

 

--_000_B8F9A780D330094D99AF023C5877DABA9A9956B2nkgeml513mbxchi_-- From nobody Mon Jul 3 03:01:29 2017 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C860131448; Mon, 3 Jul 2017 03:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9g0O_B_p4f8Q; Mon, 3 Jul 2017 03:01:26 -0700 (PDT) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (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 83F391289C3; Mon, 3 Jul 2017 03:01:22 -0700 (PDT) X-AuditID: d9a9790a-8a3ff70000003804-96-595a15ef2a95 Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id 9E.6E.14340.FE51A595; Mon, 3 Jul 2017 12:01:19 +0200 (CEST) From: Fioccola Giuseppe To: "l2sm@ietf.org" CC: "l2sm-chairs@ietf.org" , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" Thread-Topic: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-02.txt Thread-Index: AQHS8+EpuZ5uHBKUL0aASkubnonG/KJB2/cg Date: Mon, 3 Jul 2017 10:01:18 +0000 Message-ID: References: <149907514916.4930.9753967705309444500@ietfa.amsl.com> In-Reply-To: <149907514916.4930.9753967705309444500@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.240] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsXCxfdHSve9aFSkwdPfkhY9jxuZLB7svMhm ceflS0YHZo8lS34yBTBGNTDaJObl5ZcklqQqpKQWJ9squWQWJ+ckZuamFimEpOakJufnKilk ptgqGSspFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/XQsLU0td QyW7wNLU4pJ8hdzU4uLE9PTMfIXUhPWCGU/+t7MXrFCqeDG7gaWBcZtUFyMHh4SAicSHLRFd jFwcQgJTmSQ6r69m62Lk5GATsJE4+OoEmC0ioCyx9VkHK4jNLDCFUWL7CQsQW1jAU+Jjw2uo Gm+JmZ9fMkLYRhJ7Zy1jBZnPIqAicXN1OUiYVyBQ4v7BwywgtpCAk8S/Be/ASjgFnCX+NCeD hBkFZCUm7F7ECLFJXOLF9BPsILaEgIDEkj3nmSFsUYmXj/+xQtgGEluX7mOBsBUltn6CqZeR WHhkMtTFehI3pk5hg7C1JZYtfM0McY6gxMmZT1gmMIrNQrJuFpKWWUhaZiFpWcDIsopRNLfC wFCvBBJ5mSWJOZmJepklmxiBieLmykquHYyvVzkfYhTgYFTi4eUWiooUYk0sK67MPcQowcGs JMIrywAU4k1JrKxKLcqPLyrNSS0+xOgDDK+JzFKiyfnAJJZXEm9oYmFpaGxhYWRoYWaKQ1hJ nLeYEWiWQDowdWWnphakFsGMY+LglGpgzPq59Ra/tdsy9pUvi0XfBpu/n3j25Gk7QYtX0Us0 fM69qCvM+8Nu+OX9p8jPUTcv/rL6eH9ayK8bp069Cci8tDqX5YPg9ZNzJ9X1sMzTNH/8v1f+ e/j95lci0+LitjqKv7zIda6suoFB8oSNmvefI4uYzvsxVewPiFqQFMcpcYX55P2mjkNnIpRY ijMSDbWYi4oTAUfvZY9BAwAA Archived-At: Subject: [L2sm] I: I-D Action: draft-ietf-l2sm-l2vpn-service-model-02.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 10:01:28 -0000 Hi All, This is the new version of the draft-ietf-l2sm-l2vpn-service-model. Most of the changes address the comments received during the L2SM interim me= eting and are reported below (and also summarized in the Appendix A). Changes in v-(02) include: o Fix figure 3 and figure 4 in section 3.4 to apply IEEE802.3 on the segment between C and CE and apply IEEE802.1Q on the segment between CE and PE. o Update Signaling Option section and add L2TP support and classify the signaling option type into BGP-L2VPN, BGP-EVPN, LDP-PWE, L2TP- PW. o Add Multicast Support in section 5.2.13, section 5.10.3 and move the text in BUM Storm Control section into section 5.10.3. o Add new section 5.3.1, section 5.4, section 5.5, section 5.6, section 5.7, section 5.8, section 5.11to explain the usage of constraint parameters and service placement related parameters. o Add new section 5.1 and 5.14 to allow augmentation and external ID References. o Add new section to discuss inter-AS support and inter-provider support with NNI and EVC, OVC. o Update Service Section 5.10 and define four type for svc-input- bandwidth and svc-output-bandwidth and add guaranteed-bw-percent parameter and related description. o Add extranet VPN support. o Remove duplicated parameters from cloud access. o Move L2CP control plane protocol parameters under connection. o Update section 5.3.3.2 to address loop avoidance issue and divide section 5.3.3.2 into Physical interface section, LAG interface section and Addressing Section. o Reference Update. Reviews and Comments are welcome Thanks, Giuseppe -----Messaggio originale----- Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di internet-drafts@ietf.or= g Inviato: luned=EC 3 luglio 2017 11:46 A: i-d-announce@ietf.org Cc: l2sm@ietf.org Oggetto: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directori= es. This draft is a work item of the L2VPN Service Model of the IETF. Title : A YANG Data Model for L2VPN Service Delivery Authors : Bin Wen Giuseppe Fioccola Chongfeng Xie Luay Jalil Filename : draft-ietf-l2sm-l2vpn-service-model-02.txt Pages : 160 Date : 2017-07-03 Abstract: This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The data model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-02 https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2sm-l2vpn-service-model-02 Please note that it may take a couple of minutes from the time of submission= until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ L2sm mailing list L2sm@ietf.org https://www.ietf.org/mailman/listinfo/l2sm Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. From nobody Tue Jul 4 02:34:06 2017 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED0B131CA3; Tue, 4 Jul 2017 02:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o4ekuHEWpvJ; Tue, 4 Jul 2017 02:34:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2409131CA1; Tue, 4 Jul 2017 02:34:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJS11787; Tue, 04 Jul 2017 09:33:58 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 4 Jul 2017 10:33:57 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 4 Jul 2017 17:33:51 +0800 From: Qin Wu To: Fioccola Giuseppe , "l2sm@ietf.org" CC: "l2sm-chairs@ietf.org" , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" Thread-Topic: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-02.txt Thread-Index: AQHS8+EzfK6mbNUMvESHBBXpl3vPRaJBWMIAgAIPkAA= Date: Tue, 4 Jul 2017 09:33:50 +0000 Message-ID: References: <149907514916.4930.9753967705309444500@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.595B6106.0134, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d3abeaebcd91beeca32c5a60d8407f40 Archived-At: Subject: Re: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-02.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 09:34:04 -0000 VGhhbmsgR2l1c2VwcGUgdG8gc3RlcCB1cCBhbmQgbW92ZSB0aGlzIHdvcmsgZm9yd2FyZC4NCkkg YW0gZ2xhZCB0byBzZWUgYSBsb3Qgb2YgcHJvZ3Jlc3Mgd2UgbWFkZSB0byBnZXQgaW4gbGluZSB3 aXRoIEwzU00gd29yayBhbmQgYWRkcmVzcyBtb3N0IG9mIGNvbW1lbnRzIHJhaXNlZCBpbiB0aGUg aW50ZXJpbSBtZWV0aW5nLg0KUGxlYXNlIHJldmlldyB0aGUgY2hhbmdlcyBhbmQgbGV0IHVzIGtu b3cgaWYgeW91IGhhdmUgYW55IG90aGVyIGNvbW1lbnRzLg0KDQpSZWdhcmRzIQ0KUWluL0Fkcmlh bg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IEZpb2Njb2xhIEdpdXNlcHBlIFttYWlsdG86 Z2l1c2VwcGUuZmlvY2NvbGFAdGVsZWNvbWl0YWxpYS5pdF0gDQq3osvNyrG85DogMjAxN8TqN9TC M8jVIDE4OjAxDQrK1bz+yMs6IGwyc21AaWV0Zi5vcmcNCrOty806IGwyc20tY2hhaXJzQGlldGYu b3JnOyBkcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbEBpZXRmLm9yZw0K1vfM4jog STogW0wyc21dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVs LTAyLnR4dA0KDQpIaSBBbGwsDQpUaGlzIGlzIHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQt aWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwuDQpNb3N0IG9mIHRoZSBjaGFuZ2VzIGFkZHJl c3MgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGR1cmluZyB0aGUgTDJTTSBpbnRlcmltIG1lZXRpbmcg YW5kIGFyZSByZXBvcnRlZCBiZWxvdyAoYW5kIGFsc28gc3VtbWFyaXplZCBpbiB0aGUgQXBwZW5k aXggQSkuIA0KDQogICBDaGFuZ2VzIGluIHYtKDAyKSBpbmNsdWRlOg0KDQogICBvICBGaXggZmln dXJlIDMgYW5kIGZpZ3VyZSA0IGluIHNlY3Rpb24gMy40IHRvIGFwcGx5IElFRUU4MDIuMyBvbiB0 aGUNCiAgICAgIHNlZ21lbnQgYmV0d2VlbiBDIGFuZCBDRSBhbmQgYXBwbHkgSUVFRTgwMi4xUSBv biB0aGUgc2VnbWVudA0KICAgICAgYmV0d2VlbiBDRSBhbmQgUEUuDQoNCiAgIG8gIFVwZGF0ZSBT aWduYWxpbmcgT3B0aW9uIHNlY3Rpb24gYW5kIGFkZCBMMlRQIHN1cHBvcnQgYW5kIGNsYXNzaWZ5 DQogICAgICB0aGUgc2lnbmFsaW5nIG9wdGlvbiB0eXBlIGludG8gQkdQLUwyVlBOLCBCR1AtRVZQ TiwgTERQLVBXRSwgTDJUUC0NCiAgICAgIFBXLg0KDQogICBvICBBZGQgTXVsdGljYXN0IFN1cHBv cnQgaW4gc2VjdGlvbiA1LjIuMTMsIHNlY3Rpb24gNS4xMC4zIGFuZCBtb3ZlDQogICAgICB0aGUg dGV4dCBpbiBCVU0gU3Rvcm0gQ29udHJvbCBzZWN0aW9uIGludG8gc2VjdGlvbiA1LjEwLjMuDQoN CiAgIG8gIEFkZCBuZXcgc2VjdGlvbiA1LjMuMSwgc2VjdGlvbiA1LjQsIHNlY3Rpb24gNS41LCBz ZWN0aW9uIDUuNiwNCiAgICAgIHNlY3Rpb24gNS43LCBzZWN0aW9uIDUuOCwgc2VjdGlvbiA1LjEx dG8gZXhwbGFpbiB0aGUgdXNhZ2Ugb2YNCiAgICAgIGNvbnN0cmFpbnQgcGFyYW1ldGVycyBhbmQg c2VydmljZSBwbGFjZW1lbnQgcmVsYXRlZCBwYXJhbWV0ZXJzLg0KDQogICBvICBBZGQgbmV3IHNl Y3Rpb24gNS4xIGFuZCA1LjE0IHRvIGFsbG93IGF1Z21lbnRhdGlvbiBhbmQgZXh0ZXJuYWwgSUQN CiAgICAgIFJlZmVyZW5jZXMuDQoNCiAgIG8gIEFkZCBuZXcgc2VjdGlvbiB0byBkaXNjdXNzIGlu dGVyLUFTIHN1cHBvcnQgYW5kIGludGVyLXByb3ZpZGVyDQogICAgICBzdXBwb3J0IHdpdGggTk5J IGFuZCBFVkMsIE9WQy4NCg0KICAgbyAgVXBkYXRlIFNlcnZpY2UgU2VjdGlvbiA1LjEwIGFuZCBk ZWZpbmUgZm91ciB0eXBlIGZvciBzdmMtaW5wdXQtDQogICAgICBiYW5kd2lkdGggYW5kIHN2Yy1v dXRwdXQtYmFuZHdpZHRoIGFuZCBhZGQgZ3VhcmFudGVlZC1idy1wZXJjZW50DQogICAgICBwYXJh bWV0ZXIgYW5kIHJlbGF0ZWQgZGVzY3JpcHRpb24uDQoNCiAgIG8gIEFkZCBleHRyYW5ldCBWUE4g c3VwcG9ydC4NCg0KICAgbyAgUmVtb3ZlIGR1cGxpY2F0ZWQgcGFyYW1ldGVycyBmcm9tIGNsb3Vk IGFjY2Vzcy4NCg0KICAgbyAgTW92ZSBMMkNQIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgcGFyYW1l dGVycyB1bmRlciBjb25uZWN0aW9uLg0KDQogICBvICBVcGRhdGUgc2VjdGlvbiA1LjMuMy4yIHRv IGFkZHJlc3MgbG9vcCBhdm9pZGFuY2UgaXNzdWUgYW5kIGRpdmlkZQ0KICAgICAgc2VjdGlvbiA1 LjMuMy4yIGludG8gUGh5c2ljYWwgaW50ZXJmYWNlIHNlY3Rpb24sIExBRyBpbnRlcmZhY2UNCiAg ICAgIHNlY3Rpb24gYW5kIEFkZHJlc3NpbmcgU2VjdGlvbi4NCg0KICAgbyAgUmVmZXJlbmNlIFVw ZGF0ZS4NCg0KUmV2aWV3cyBhbmQgQ29tbWVudHMgYXJlIHdlbGNvbWUNCg0KVGhhbmtzLA0KDQpH aXVzZXBwZQ0KDQotLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KRGE6IEwyc20gW21haWx0 bzpsMnNtLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcNCkludmlhdG86IGx1bmVkqKwgMyBsdWdsaW8gMjAxNyAxMTo0Ng0KQTogaS1kLWFubm91 bmNlQGlldGYub3JnDQpDYzogbDJzbUBpZXRmLm9yZw0KT2dnZXR0bzogW0wyc21dIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLTAyLnR4dA0KDQoNCkEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEwyVlBO IFNlcnZpY2UgTW9kZWwgb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDog QSBZQU5HIERhdGEgTW9kZWwgZm9yIEwyVlBOIFNlcnZpY2UgRGVsaXZlcnkNCiAgICAgICAgQXV0 aG9ycyAgICAgICAgIDogQmluIFdlbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBHaXVzZXBw ZSBGaW9jY29sYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBDaG9uZ2ZlbmcgWGllDQogICAg ICAgICAgICAgICAgICAgICAgICAgIEx1YXkgSmFsaWwNCglGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC0wMi50eHQNCglQYWdlcyAgICAgICAgICAg OiAxNjANCglEYXRlICAgICAgICAgICAgOiAyMDE3LTA3LTAzDQoNCkFic3RyYWN0Og0KICAgVGhp cyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIHRoYXQgY2FuIGJlIHVzZWQgdG8g Y29uZmlndXJlDQogICBhIExheWVyIDIgUHJvdmlkZXIgUHJvdmlzaW9uZWQgVlBOIHNlcnZpY2Uu DQoNCiAgIFRoaXMgbW9kZWwgaXMgaW50ZW5kZWQgdG8gYmUgaW5zdGFudGlhdGVkIGF0IG1hbmFn ZW1lbnQgc3lzdGVtIHRvDQogICBkZWxpdmVyIHRoZSBvdmVyYWxsIHNlcnZpY2UuICBUaGlzIG1v ZGVsIGlzIG5vdCBhIGNvbmZpZ3VyYXRpb24gbW9kZWwNCiAgIHRvIGJlIHVzZWQgZGlyZWN0bHkg b24gbmV0d29yayBlbGVtZW50cywgYnV0IHByb3ZpZGVzIGFuIGFic3RyYWN0ZWQNCiAgIHZpZXcg b2YgdGhlIExheWVyIDIgVlBOIHNlcnZpY2UgY29uZmlndXJhdGlvbiBjb21wb25lbnRzLiAgSXQg aXMgdXANCiAgIHRvIGEgbWFuYWdlbWVudCBzeXN0ZW0gdG8gdGFrZSB0aGlzIGFzIGFuIGlucHV0 IGFuZCBnZW5lcmF0ZSBzcGVjaWZpYw0KICAgY29uZmlndXJhdGlvbnMgbW9kZWxzIHRvIGNvbmZp Z3VyZSB0aGUgZGlmZmVyZW50IG5ldHdvcmsgZWxlbWVudHMgdG8NCiAgIGRlbGl2ZXIgdGhlIHNl cnZpY2UuICBIb3cgY29uZmlndXJhdGlvbiBvZiBuZXR3b3JrIGVsZW1lbnRzIGlzIGRvbmUNCiAg IGlzIG91dCBvZiBzY29wZSBvZiB0aGUgZG9jdW1lbnQuDQoNCiAgIFRoZSBkYXRhIG1vZGVsIGlu IHRoaXMgZG9jdW1lbnQgaW5jbHVkZXMgc3VwcG9ydCBmb3IgcG9pbnQtdG8tcG9pbnQNCiAgIFZp cnR1YWwgUHJpdmF0ZSBXaXJlIFNlcnZpY2VzIChWUFdTKSBhbmQgbXVsdGlwb2ludCBWaXJ0dWFs IFByaXZhdGUNCiAgIExBTiBzZXJ2aWNlcyAoVlBMUykgdGhhdCB1c2UgUHNldWRvd2lyZXMgc2ln bmFsZWQgdXNpbmcgdGhlIExhYmVsDQogICBEaXN0cmlidXRpb24gUHJvdG9jb2wgKExEUCkgYW5k IHRoZSBCb3JkZXIgR2F0ZXdheSBQcm90b2NvbCAoQkdQKSBhcw0KICAgZGVzY3JpYmVkIGluIFJG QzQ3NjEgYW5kIFJGQzY2MjQuDQoNCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1s aXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwtMDINCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwt MDINCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbDJzbS1sMnZwbi1z ZXJ2aWNlLW1vZGVsLTAyDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTDJzbSBtYWlsaW5nIGxpc3QNCkwyc21AaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDJzbQ0KDQpRdWVz dG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZh bWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxz aWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGlu Zm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJp Y2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJl Z2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHBy b3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gDQoNClRoaXMgZS1tYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3Nl bWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5h dXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNl bmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuIA0KDQpSaXNwZXR0YSBsJ2FtYmllbnRlLiBO b24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIKioIG5lY2Vzc2FyaW8uDQo= From nobody Wed Jul 5 04:47:05 2017 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A6131CB1; Wed, 5 Jul 2017 04:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM7Ype992sMa; Wed, 5 Jul 2017 04:46:54 -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 E51E01201F2; Wed, 5 Jul 2017 04:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21030; q=dns/txt; s=iport; t=1499255214; x=1500464814; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=dTFq98eIp6497IQTho8vJKS9aCS9Hx3O+Kcf7Jt5yco=; b=CKjuK09NHW71/VyPZq2V31qsS8V9FbVRMZjoAyHZmeNQp98+u7f94AIk 9gwEZaOPKrLneuhfUbPyp6yBjOf7L1lPd4vHx6yYk6sTfL5t5PgoLNE5F RIFal5Qk3HMjzb0hTf64RlxkWox9oI6+k/LoDHoU0uf7q+rhIVinJLtzo M=; X-IronPort-AV: E=Sophos;i="5.40,311,1496102400"; d="scan'208,217";a="655883765" 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; 05 Jul 2017 11:46:52 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v65BkpvW007462; Wed, 5 Jul 2017 11:46:51 GMT To: Qin Wu , "l3sm@ietf.org" , "l2sm@ietf.org" Cc: "Benoit Claise (bclaise)" , "adrian@olddog.co.uk" References: From: David Ball Message-ID: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> Date: Wed, 5 Jul 2017 12:46:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CFA03018E87AF0C12433CD5A" Content-Language: en-GB Archived-At: Subject: Re: [L2sm] [L3sm] Followup of RFC8049bis X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 11:46:58 -0000 This is a multi-part message in MIME format. --------------CFA03018E87AF0C12433CD5A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Qin. I thought it might be useful to summarize the discussion on each of my original questions so far. In general, I imagine that if I had a question, other readers might have the same question too, so even if we have answered the question on the thread, I think it is good to provide the clarification in the text as well. 1. You mention below that you think this is already described in section 6.6 and 6.12. However, the fact that the model only covers information requested by the customer to the SP is a key aspect of the model that is critical to the reader's understanding, so I think it needs to be explained much more clearly, and much earlier in the document i.e. in section 5. 2. As far as I saw, you only added one sentence about this - I think a bit more is needed! In fact I wonder if we are even all on the same page in the emails, since your answer didn't seem to quite align with what Kenichi and Stephane said. 3. I didn't see any text added to address this - and again, I'm not sure we're all on the same page yet. Kenichi agreed that there is no technical difference between using SubVPN and using multiple sites, although obviously this is related to question 2. At the very least, the ambiguity in the existing text should be fixed! 4. Addressed in the new draft 5. Conclusion is that using a single VPN service for multiple clouds is technically the same as using a separate VPN service for each cloud, but it might be easier operationally. This needs to be explained in the draft. 6. Addressed in the new draft 7. Can be addressed with an augment, so no change needed 8. You agreed to add some additional explanation about MTU, but I didn't see any changes in the draft? 9. Conclusion was that max routes per VPN might be useful but hard to implement, so no change needed. 10. Per-VPN QoS policy can be achieved in most cases using the target-sites option - need to add text to explain this 11. Can specify different performance objectives by using more classes, no change needed 12. I still don't understand what the SP is supposed to do in a multipoint case where end-to-end is true. Actually, even in a P2P case, there is a problem if the guaranteed end-to-end bandwidth is specified differently at each end. Should the SP take the higher or lower value? 13. Routing: 1. Agreed no change needed 2. Agreed no change needed 3. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer. Need to explain this in the text. 4. Addressed in the new draft 5. I did not understand your comment about the BGP AS number below - all the attributes in the model are applied at the customer to SP boundary, but it still needs to be clarified whether it is the customer's or SP's AS number. Actually given that the model is only covering what the customer requests, I guess it would always be the customer's AS number (since the customer wouldn't need to request the SP's AS number, that would be provided by the SP to the customer, which is outside the scope of the model). So I think the text should clarify that this is the customer's AS number. 6. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer. Need to explain this in the text. 7. Number of BGP sessions - SP decides and tells the customer, so this is outside the scope. Need to clarify in the text. 8. Model does not cover the case of eBGP multihop between loopbacks - need to mention this in the text. 9. Agreed no change needed 14. I didn't see an answer from anyone on why the BFD parameters can only be specified per access link. It seems useful to me to allow them to be specified per site too, like many other attributes. 15. Connection Addressing: 1. I saw you added the provider address and mask to the model for the DHCP and DHCP relay cases - but if the model is only covering information requested by the customer, then this doesn't seem right. Instead, the text should explain that they are supplied by the SP and thus are outside the scope of the model. 2. Addressed in the new draft - customer can request either a number of addresses or an explicit list of address ranges. 3. Agreed no change needed 4. I saw you added a leaf for this, but I'm not sure that's quite right. I'm not an IPv6 expert, but I thought LL addresses are always there; my question was not "LL addresses or global addresses?", it was "LL addresses only, or both LL and global addresses?". If it's LL only, then I don't think any of the other options apply - there is no need for static addresses, DHCP or SLAAC if the link only uses LL addresses. 16. Kenichi agreed there is an issue here, but I didn't see any fix in the new draft? 17. Not sure we reached a conclusion on this one... Thanks, David On 03/07/2017 10:52, Qin Wu wrote: > > Hi, All: > > The v-(02) of RFC8049bis has just been posted, > > https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ > > thanks Jan and David for valuable comments and input, the main changes > include: > > 1.Specify what type of IPv6 address in the model for IPv6 connection? > link-local global > > 2.Specify provider address and a list of start-end addresses from > provider address > > 3.remove redundant parameters such as deny-any-except and > permit-any-except under cloud-access? > > 4. Add a few text to clarify what the site is in section 6.3 > > 5. Add a few text to clarify why having customer-name. > > 6. Fixed two typos pointed by Jan recently. > > Talking with L3Sm design team, we believe how information is > communicated by SP to the customer is beyond the scope of > > RFC8049 has already been clarified in section 6.6, 2nd paragraph, > section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section > 6.12.2.2,4th paragraph. > > Regarding whether AS number under BGP protocol is supposed to be the > customer's AS number or the SP's AS number, we think AS number as > > part of BGP protocol related parameters are applied to provider to > customer boundary, therefore the answer is depending on > > how the management model is administered. > > As Jan pointed out, we still have some new mandatory fields introduced > in v-(02) haven’t been reflected in the examples. But he is okay with > the current shape. > > Please review these changes, let us know if there is any additional > comments. > > Regards! > > Qin (on behalf of team) > > > > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm -- David Ball --------------CFA03018E87AF0C12433CD5A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Thanks Qin.

I thought it might be useful to summarize the discussion on each of my original questions so far.  In general, I imagine that if I had a question, other readers might have the same question too, so even if we have answered the question on the thread, I think it is good to provide the clarification in the text as well.

  1. You mention below that you think this is already described in section 6.6 and 6.12.  However, the fact that the model only covers information requested by the customer to the SP is a key aspect of the model that is critical to the reader's understanding, so I think it needs to be explained much more clearly, and much earlier in the document i.e. in section 5.
  2. As far as I saw, you only added one sentence about this - I think a bit more is needed!  In fact I wonder if we are even all on the same page in the emails, since your answer didn't seem to quite align with what Kenichi and Stephane said.
  3. I didn't see any text added to address this - and again, I'm not sure we're all on the same page yet.  Kenichi agreed that there is no technical difference between using SubVPN and using multiple sites, although obviously this is related to question 2.  At the very least, the ambiguity in the existing text should be fixed!
  4. Addressed in the new draft
  5. Conclusion is that using a single VPN service for multiple clouds is technically the same as using a separate VPN service for each cloud, but it might be easier operationally.  This needs to be explained in the draft.
  6. Addressed in the new draft
  7. Can be addressed with an augment, so no change needed
  8. You agreed to add some additional explanation about MTU, but I didn't see any changes in the draft?
  9. Conclusion was that max routes per VPN might be useful but hard to implement, so no change needed.
  10. Per-VPN QoS policy can be achieved in most cases using the target-sites option - need to add text to explain this
  11. Can specify different performance objectives by using more classes, no change needed
  12. I still don't understand what the SP is supposed to do in a multipoint case where end-to-end is true.  Actually, even in a P2P case, there is a problem if the guaranteed end-to-end bandwidth is specified differently at each end.  Should the SP take the higher or lower value?
  13. Routing:
    1. Agreed no change needed
    2. Agreed no change needed
    3. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer.  Need to explain this in the text.
    4. Addressed in the new draft
    5. I did not understand your comment about the BGP AS number below - all the attributes in the model are applied at the customer to SP boundary, but it still needs to be clarified whether it is the customer's or SP's AS number.  Actually given that the model is only covering what the customer requests, I guess it would always be the customer's AS number (since the customer wouldn't need to request the SP's AS number, that would be provided by the SP to the customer, which is outside the scope of the model).  So I think the text should clarify that this is the customer's AS number.
    6. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer.  Need to explain this in the text.
    7. Number of BGP sessions - SP decides and tells the customer, so this is outside the scope.  Need to clarify in the text.
    8. Model does not cover the case of eBGP multihop between loopbacks - need to mention this in the text.
    9. Agreed no change needed
  14. I didn't see an answer from anyone on why the BFD parameters can only be specified per access link.  It seems useful to me to allow them to be specified per site too, like many other attributes.
  15. Connection Addressing:
    1. I saw you added the provider address and mask to the model for the DHCP and DHCP relay cases - but if the model is only covering information requested by the customer, then this doesn't seem right.  Instead, the text should explain that they are supplied by the SP and thus are outside the scope of the model.
    2. Addressed in the new draft - customer can request either a number of addresses or an explicit list of address ranges.
    3. Agreed no change needed
    4. I saw you added a leaf for this, but I'm not sure that's quite right.  I'm not an IPv6 expert, but I thought LL addresses are always there; my question was not "LL addresses or global addresses?", it was "LL addresses only, or both LL and global addresses?".  If it's LL only, then I don't think any of the other options apply - there is no need for static addresses, DHCP or SLAAC if the link only uses LL addresses.
  16. Kenichi agreed there is an issue here, but I didn't see any fix in the new draft?
  17. Not sure we reached a conclusion on this one...


Thanks,


    David


On 03/07/2017 10:52, Qin Wu wrote:

Hi, All:

The v-(02) of RFC8049bis has just been posted,

https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/

thanks Jan and David for valuable comments and input, the main changes include:

1.Specify what type of IPv6 address in the model for IPv6 connection? link-local global

2.Specify provider address and a list of start-end addresses from provider address

3.remove redundant parameters such as deny-any-except and permit-any-except under cloud-access?

4. Add a few text to clarify what the site is in section 6.3

5. Add a few text to clarify why having customer-name.

6. Fixed two typos pointed by Jan recently.

 

Talking with L3Sm design team, we believe how information is communicated by SP to the customer is beyond the scope of

RFC8049 has already been clarified in section 6.6, 2nd paragraph, section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section 6.12.2.2,4th paragraph.

 

Regarding whether AS number under BGP protocol is supposed to be the customer's AS number or the SP's AS number, we think AS number as

part of BGP protocol related parameters are applied to provider to customer boundary, therefore the answer is depending on

how the management model is administered.

 

As Jan pointed out, we still have some new mandatory fields introduced in v-(02) haven’t been reflected in the examples. But he is okay with the current shape.

Please review these changes, let us know if there is any additional comments.

 

Regards!

Qin (on behalf of team)

 

 



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


-- 
David Ball
<daviball@cisco.com>
--------------CFA03018E87AF0C12433CD5A-- From nobody Mon Jul 10 06:47:29 2017 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06750131784; Mon, 10 Jul 2017 06:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4kjqKJbSNpm; Mon, 10 Jul 2017 06:47:18 -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 754B9127076; Mon, 10 Jul 2017 06:47:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKC19066; Mon, 10 Jul 2017 13:47:15 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 10 Jul 2017 14:47:13 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 10 Jul 2017 21:47:06 +0800 From: Qin Wu To: David Ball , "l3sm@ietf.org" , "l2sm@ietf.org" CC: "Benoit Claise (bclaise)" , "adrian@olddog.co.uk" Thread-Topic: [L3sm] Followup of RFC8049bis Thread-Index: AdLz4gQczWlV+rrbRBePS8Ez8xfWvQBX1HKAAQwkggA= Date: Mon, 10 Jul 2017 13:47:05 +0000 Message-ID: References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> In-Reply-To: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A9A7FBDnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59638563.0233, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d3fcfc43ea9619cf635afd1f9d4aa175 Archived-At: Subject: Re: [L2sm] [L3sm] Followup of RFC8049bis X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 13:47:22 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9A9A7FBDnkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 t6K8/sjLOiBEYXZpZCBCYWxsIFttYWlsdG86ZGF2aWJhbGxAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6 IDIwMTfE6jfUwjXI1SAxOTo0Nw0KytW8/sjLOiBRaW4gV3U7IGwzc21AaWV0Zi5vcmc7IGwyc21A aWV0Zi5vcmcNCrOty806IEJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpOyBhZHJpYW5Ab2xkZG9nLmNv LnVrDQrW98ziOiBSZTogW0wzc21dIEZvbGxvd3VwIG9mIFJGQzgwNDliaXMNCg0KDQpUaGFua3Mg UWluLg0KDQpJIHRob3VnaHQgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIHN1bW1hcml6ZSB0aGUgZGlz Y3Vzc2lvbiBvbiBlYWNoIG9mIG15IG9yaWdpbmFsIHF1ZXN0aW9ucyBzbyBmYXIuICBJbiBnZW5l cmFsLCBJIGltYWdpbmUgdGhhdCBpZiBJIGhhZCBhIHF1ZXN0aW9uLCBvdGhlciByZWFkZXJzIG1p Z2h0IGhhdmUgdGhlIHNhbWUgcXVlc3Rpb24gdG9vLCBzbyBldmVuIGlmIHdlIGhhdmUgYW5zd2Vy ZWQgdGhlIHF1ZXN0aW9uIG9uIHRoZSB0aHJlYWQsIEkgdGhpbmsgaXQgaXMgZ29vZCB0byBwcm92 aWRlIHRoZSBjbGFyaWZpY2F0aW9uIGluIHRoZSB0ZXh0IGFzIHdlbGwuDQoNCiAgMS4gIFlvdSBt ZW50aW9uIGJlbG93IHRoYXQgeW91IHRoaW5rIHRoaXMgaXMgYWxyZWFkeSBkZXNjcmliZWQgaW4g c2VjdGlvbiA2LjYgYW5kIDYuMTIuICBIb3dldmVyLCB0aGUgZmFjdCB0aGF0IHRoZSBtb2RlbCBv bmx5IGNvdmVycyBpbmZvcm1hdGlvbiByZXF1ZXN0ZWQgYnkgdGhlIGN1c3RvbWVyIHRvIHRoZSBT UCBpcyBhIGtleSBhc3BlY3Qgb2YgdGhlIG1vZGVsIHRoYXQgaXMgY3JpdGljYWwgdG8gdGhlIHJl YWRlcidzIHVuZGVyc3RhbmRpbmcsIHNvIEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgZXhwbGFpbmVk IG11Y2ggbW9yZSBjbGVhcmx5LCBhbmQgbXVjaCBlYXJsaWVyIGluIHRoZSBkb2N1bWVudCBpLmUu IGluIHNlY3Rpb24gNS4NCiAgICAgIFtRaW5dOiBZb3UgbmVlZCB0byByZWFkIGNhcmVmdWxseSwg aXQgY2xlYXJseSBleHBsYWluIHdoYXQga2luZCBvZiBpbmZvcm1hdGlvbiByZXNwb25kZWQgYnkg U1AgdG8gdGhlIEN1c3RvbWVyIGlzIG5vdCBpbiB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4g Rm9yIG1vc3Qgb2Ygb3RoZXIgaW5mb3JtYXRpb24sIGl0IGRvZXNuoa90IHJlcXVpcmUgU1AgdG8g cmVzcG9uZCBiYWNrIHRvIEN1c3RvbWVyLg0KU2VlIHNlY3Rpb24gNi42ICwgM3JkIHBhcmFncmFw aDoNCqGwSWYgYSBjb25zdHJhaW50IGlzIHRvbyBzdHJpY3QgYW5kIGNhbm5vdCBiZSBmdWxmaWxs ZWQsIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSBNVVNUIE5PVCBwcm92aXNpb24gdGhlIHNpdGUgYW5k IFNIT1VMRCBwcm92aWRlIHJlbGV2YW50IGluZm9ybWF0aW9uIHRvIHRoZSB1c2VyLqGxDQpTZWUg c2VjdGlvbiA2LjYuMyAybmQgcGFyYWdyYXBoICwxc3QgYnVsbGV0Og0KobBJZiB0aGUgInN0cmlj dCIgbGVhZiBpcyBlcXVhbCB0byAiZmFsc2UiKGRlZmF1bHQpIGFuZCBpZiB0aGUgcmVxdWVzdGVk IG1lZGlhIHR5cGUgY2Fubm90IGJlIGZ1bGZpbGxlZCwgdGhlIG1hbmFnZW1lbnQgc3lzdGVtIGNh biBzZWxlY3QgYW5vdGhlciBtZWRpYSB0eXBlLiAgVGhlIHN1cHBvcnRlZCBtZWRpYSB0eXBlcyBT SE9VTEQgYmUgY29tbXVuaWNhdGVkIGJ5IHRoZSBTUCB0byB0aGUgY3VzdG9tZXIgdmlhIGEgbWVj aGFuaXNtIHRoYXQgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50LqGxDQpTZWUgc2Vj dGlvbiA2LjEyLjIuMiw0dGggcGFyYWdyYXBoOg0KobBzb21lIGNvbnN0cmFpbnRzIG1heSBub3Qg YmUgY29tcGxldGVseSBmdWxmaWxsZWQgYnkgdGhlIFNQOyBpbiB0aGlzIGNhc2UsIHRoZSBTUCBz aG91bGQgYWR2aXNlIHRoZSBjdXN0b21lciBhYm91dCB0aGUgbGltaXRhdGlvbnMuICBIb3cgdGhp cyBjb21tdW5pY2F0aW9uIGlzIGRvbmUgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50 LqGxDQoNCiAgMS4gIEFzIGZhciBhcyBJIHNhdywgeW91IG9ubHkgYWRkZWQgb25lIHNlbnRlbmNl IGFib3V0IHRoaXMgLSBJIHRoaW5rIGEgYml0IG1vcmUgaXMgbmVlZGVkISAgSW4gZmFjdCBJIHdv bmRlciBpZiB3ZSBhcmUgZXZlbiBhbGwgb24gdGhlIHNhbWUgcGFnZSBpbiB0aGUgZW1haWxzLCBz aW5jZSB5b3VyIGFuc3dlciBkaWRuJ3Qgc2VlbSB0byBxdWl0ZSBhbGlnbiB3aXRoIHdoYXQgS2Vu aWNoaSBhbmQgU3RlcGhhbmUgc2FpZC4NCltRaW5dOiBTaXRlIG5vdGlvbiBoYXMgYmVlbiB3ZWxs IGNsYXJpZmllZCBpbiB0aGUgZG9jdW1lbnQ6DQoNCqGwICAgQSBzaXRlIGhhcyBzZXZlcmFsIGNo YXJhY3RlcmlzdGljczoNCg0KICAgbyAgVW5pcXVlIGlkZW50aWZpZXIgKHNpdGUtaWQpOiB1bmlx dWVseSBpZGVudGlmaWVzIHRoZSBzaXRlIHdpdGhpbg0KICAgICAgdGhlIG92ZXJhbGwgbmV0d29y ayBpbmZyYXN0cnVjdHVyZS4gIFRoZSBpZGVudGlmaWVyIGlzIGEgc3RyaW5nDQogICAgICB0aGF0 IGFsbG93cyBhbnkgZW5jb2RpbmcgZm9yIHRoZSBsb2NhbCBhZG1pbmlzdHJhdGlvbiBvZiB0aGUg VlBODQogICAgICBzZXJ2aWNlLg0KDQogICBvICBMb2NhdGlvbnMgKGxvY2F0aW9ucyk6IHNpdGUg bG9jYXRpb24gaW5mb3JtYXRpb24gdGhhdCBhbGxvd3MgZWFzeQ0KICAgICAgcmV0cmlldmFsIG9m IGluZm9ybWF0aW9uIGZyb20gdGhlIG5lYXJlc3QgYXZhaWxhYmxlIHJlc291cmNlcy4gIEENCiAg ICAgIHNpdGUgbWF5IGJlIGNvbXBvc2VkIG9mIG11bHRpcGxlIGxvY2F0aW9ucy4NCg0KICAgbyAg RGV2aWNlcyAoZGV2aWNlcyk6IGFsbG93cyB0aGUgY3VzdG9tZXIgdG8gcmVxdWVzdCBvbmUgb3Ig bW9yZQ0KICAgICAgY3VzdG9tZXIgcHJlbWlzZXMgZXF1aXBtZW50IGVudGl0aWVzIGZyb20gdGhl IFNQIGZvciBhIHBhcnRpY3VsYXINCiAgICAgIHNpdGUuDQoNCiAgIG8gIE1hbmFnZW1lbnQgKG1h bmFnZW1lbnQpOiBkZWZpbmVzIHRoZSB0eXBlIG9mIG1hbmFnZW1lbnQgZm9yIHRoZQ0KICAgICAg c2l0ZSAtLSBmb3IgZXhhbXBsZSwgY28tbWFuYWdlZCwgY3VzdG9tZXItbWFuYWdlZCwgb3IgcHJv dmlkZXItDQogICAgICBtYW5hZ2VkLiAgU2VlIFNlY3Rpb24gNi4xMDxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtd3UtbDNzbS1yZmM4MDQ5YmlzLTAxI3NlY3Rpb24tNi4xMD4uDQoN CiAgIG8gIFNpdGUgbmV0d29yayBhY2Nlc3NlcyAoc2l0ZS1uZXR3b3JrLWFjY2Vzc2VzKTogZGVm aW5lcyB0aGUgbGlzdCBvZg0KICAgICAgbmV0d29yayBhY2Nlc3NlcyBhc3NvY2lhdGVkIHdpdGgg dGhlIHNpdGVzLCBhbmQgdGhlaXIgcHJvcGVydGllcw0KICAgICAgLS0gZXNwZWNpYWxseSBiZWFy ZXIsIGNvbm5lY3Rpb24sIGFuZCBzZXJ2aWNlIHBhcmFtZXRlcnMuDQqhsQ0KSSBhZGQgb25lIHNl bnRlbmNlIHRvIGdldCBjb25zaXN0IHdpdGggdGhpcy4gVGhlIHByb3Bvc2VkIGNoYW5nZXMgaGF2 ZSBnb3QgYXBwcm92ZWQgYnkgU3RlcGFuZSBhbmQgS2VuaWNoaSBhbHJlYWR5IGJlZm9yZSBwb3N0 aW5nIHRvIHRoZSBsaXN0Lg0KDQogIDEuICBJIGRpZG4ndCBzZWUgYW55IHRleHQgYWRkZWQgdG8g YWRkcmVzcyB0aGlzIC0gYW5kIGFnYWluLCBJJ20gbm90IHN1cmUgd2UncmUgYWxsIG9uIHRoZSBz YW1lIHBhZ2UgeWV0LiAgS2VuaWNoaSBhZ3JlZWQgdGhhdCB0aGVyZSBpcyBubyB0ZWNobmljYWwg ZGlmZmVyZW5jZSBiZXR3ZWVuIHVzaW5nIFN1YlZQTiBhbmQgdXNpbmcgbXVsdGlwbGUgc2l0ZXMs IGFsdGhvdWdoIG9idmlvdXNseSB0aGlzIGlzIHJlbGF0ZWQgdG8gcXVlc3Rpb24gMi4gIEF0IHRo ZSB2ZXJ5IGxlYXN0LCB0aGUgYW1iaWd1aXR5IGluIHRoZSBleGlzdGluZyB0ZXh0IHNob3VsZCBi ZSBmaXhlZCENCltRaW5dOkkgdGhpbmsgdGhlIGtleSBkaWZmZXJlbmNlIGJldHdlZW4gc3ViVlBO IGFuZCBtdWx0aS1WUE4gaXMgd2hldGhlciB0aGV5IHNoYXJlIHRoZSBzYW1lIGJlYXJlci4gSXQg aXMgY2xhcmlmaWVkIGluIHRoZSBzZWN0aW9uIDYuNS4xLjMNCqGwDQpJdCBpcyBzaW1pbGFyIHRv IGhhdmluZyBzZXBhcmF0ZSBzaXRlcywgYnV0IGluIHRoaXMgY2FzZSB0aGUgY3VzdG9tZXINCndh bnRzIHRvIHNoYXJlIHNvbWUgcGh5c2ljYWwgY29tcG9uZW50cyB3aGlsZSBtYWludGFpbmluZyBz dHJvbmcgY29tbXVuaWNhdGlvbiBpc29sYXRpb24gYmV0d2VlbiB0aGUgYWZmaWxpYXRlcy4NCqGx DQpQaHlzaWNhbCBjb21wb25lbnRzIGFyZSByZWZlcnJlZCB0byB0aGUgYmVhcmVyLg0KSSB0aGlu ayB0aGlzIGlzIHN1ZmZpY2llbnQuIElmIHlvdSB0aGluayB3ZSBzaG91bGQgZnVydGhlciBsaW1p dCBzdWJWUE4gdG8gdGhlIHNhbWUgYmVhcmVyIGFuZCBzYW1lIENQRSwgcGxlYXNlIGxldCBtZSBr bm93Lg0KDQogIDEuICBBZGRyZXNzZWQgaW4gdGhlIG5ldyBkcmFmdA0KICAyLiAgQ29uY2x1c2lv biBpcyB0aGF0IHVzaW5nIGEgc2luZ2xlIFZQTiBzZXJ2aWNlIGZvciBtdWx0aXBsZSBjbG91ZHMg aXMgdGVjaG5pY2FsbHkgdGhlIHNhbWUgYXMgdXNpbmcgYSBzZXBhcmF0ZSBWUE4gc2VydmljZSBm b3IgZWFjaCBjbG91ZCwgYnV0IGl0IG1pZ2h0IGJlIGVhc2llciBvcGVyYXRpb25hbGx5LiAgVGhp cyBuZWVkcyB0byBiZSBleHBsYWluZWQgaW4gdGhlIGRyYWZ0Lg0KW1Fpbl06IEkgYmVsaWV2ZSB1 c2luZyBhIHNlcGFyYXRlIFZQTiBzZXJ2aWNlIGZvciBlYWNoIGNsb3VkIGlzIG5vdCBpbiB0aGUg c2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gVGhpcyBkcmFmdCBjbGVhciBleHBsYWluZWQgdG8gc3Vw cG9ydCBwdWJsaWMgY2xvdWQgYWNjZXNzLCBzdXBwb3J0IHByaXZhdGUgY2xvdWQgYWNjZXNzIHdp dGggYSBzaW5nbGUgVlBOIHNlcnZpY2UuDQoNCiAgMS4gIEFkZHJlc3NlZCBpbiB0aGUgbmV3IGRy YWZ0DQogIDIuICBDYW4gYmUgYWRkcmVzc2VkIHdpdGggYW4gYXVnbWVudCwgc28gbm8gY2hhbmdl IG5lZWRlZA0KDQpbUWluXTogQWdyZWUsIGRvIHlvdSB0aGluayBzZWN0aW9uIDYuMSChsEZlYXR1 cmVzIGFuZCBBdWdtZW50YXRpb26hsSBpcyBzdWZmaWNpZW50IHRvIGFkZHJlc3MgeW91ciBjb21t ZW50IHdpdGggYW55IHRleHQgY2hhbmdlLg0KDQogIDEuICBZb3UgYWdyZWVkIHRvIGFkZCBzb21l IGFkZGl0aW9uYWwgZXhwbGFuYXRpb24gYWJvdXQgTVRVLCBidXQgSSBkaWRuJ3Qgc2VlIGFueSBj aGFuZ2VzIGluIHRoZSBkcmFmdD8NCltRaW5dOkFkZHJlc3NlZCBpbiB0aGUgcHJldmlvdXMgdmVy c2lvbiB3aGljaCBhZGRyZXNzIEphbqGvcyBjb21tZW50cywgU2VlDQqhsA0KICAgICBsZWFmIHN2 Yy1tdHUgew0KICAgICAgIHR5cGUgdWludDE2Ow0KICAgICAgIHVuaXRzIGJ5dGVzOw0KICAgICAg IG1hbmRhdG9yeSB0cnVlOw0KICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICJNVFUgYXQgc2Vy dmljZSBsZXZlbC4gSWYgdGhlIHNlcnZpY2UgaXMgSVAsDQogICAgICAgICBpdCByZWZlcnMgdG8g dGhlIElQIE1UVS4gSWYgQ3NDIGlzIGVuYWJsZWQsDQogICAgICAgICB0aGUgcmVxdWVzdGVkICdz dmMtbXR1JyBsZWFmIHdpbGwgcmVmZXIgdG8gdGhlDQogICAgICAgICBNUExTIE1UVSBhbmQgbm90 IHRvIHRoZSBJUCBNVFUuICI7DQqhsQ0KDQogIDEuICBDb25jbHVzaW9uIHdhcyB0aGF0IG1heCBy b3V0ZXMgcGVyIFZQTiBtaWdodCBiZSB1c2VmdWwgYnV0IGhhcmQgdG8gaW1wbGVtZW50LCBzbyBu byBjaGFuZ2UgbmVlZGVkLg0KICAyLiAgUGVyLVZQTiBRb1MgcG9saWN5IGNhbiBiZSBhY2hpZXZl ZCBpbiBtb3N0IGNhc2VzIHVzaW5nIHRoZSB0YXJnZXQtc2l0ZXMgb3B0aW9uIC0gbmVlZCB0byBh ZGQgdGV4dCB0byBleHBsYWluIHRoaXMNCltRaW5dOiBPa2F5Lg0KDQogIDEuICBDYW4gc3BlY2lm eSBkaWZmZXJlbnQgcGVyZm9ybWFuY2Ugb2JqZWN0aXZlcyBieSB1c2luZyBtb3JlIGNsYXNzZXMs IG5vIGNoYW5nZSBuZWVkZWQNCiAgMi4gIEkgc3RpbGwgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRo ZSBTUCBpcyBzdXBwb3NlZCB0byBkbyBpbiBhIG11bHRpcG9pbnQgY2FzZSB3aGVyZSBlbmQtdG8t ZW5kIGlzIHRydWUuICBBY3R1YWxseSwgZXZlbiBpbiBhIFAyUCBjYXNlLCB0aGVyZSBpcyBhIHBy b2JsZW0gaWYgdGhlIGd1YXJhbnRlZWQgZW5kLXRvLWVuZCBiYW5kd2lkdGggaXMgc3BlY2lmaWVk IGRpZmZlcmVudGx5IGF0IGVhY2ggZW5kLiAgU2hvdWxkIHRoZSBTUCB0YWtlIHRoZSBoaWdoZXIg b3IgbG93ZXIgdmFsdWU/DQoNCltRaW5dOiBJIHRoaW5rIHRoaXMgZGVwZW5kcyBvbiB0aGUgU1An cyBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc2VydmljZS4NCg0KICAxLiAgUm91dGluZzoNCiAgICAg KiAgIEFncmVlZCBubyBjaGFuZ2UgbmVlZGVkDQogICAgICogICBBZ3JlZWQgbm8gY2hhbmdlIG5l ZWRlZA0KICAgICAqICAgQ29uY2x1ZGVkIHRoYXQgb3RoZXIgcGFyYW1ldGVycyAodGltZXJzIGV0 YykgYXJlIHNldCBieSB0aGUgU1AgYW5kIGNvbW11bmljYXRlZCBvdXRzaWRlIG9mIHRoZSBtb2Rl bCwgbm90IHJlcXVlc3RlZCBieSB0aGUgY3VzdG9tZXIuICBOZWVkIHRvIGV4cGxhaW4gdGhpcyBp biB0aGUgdGV4dC4NCiAgICAgICAgICAgICAgICAgICAgW1Fpbl06IE9rYXkuDQoNCiAgICAgKiAg IEFkZHJlc3NlZCBpbiB0aGUgbmV3IGRyYWZ0DQogICAgICogICBJIGRpZCBub3QgdW5kZXJzdGFu ZCB5b3VyIGNvbW1lbnQgYWJvdXQgdGhlIEJHUCBBUyBudW1iZXIgYmVsb3cgLSBhbGwgdGhlIGF0 dHJpYnV0ZXMgaW4gdGhlIG1vZGVsIGFyZSBhcHBsaWVkIGF0IHRoZSBjdXN0b21lciB0byBTUCBi b3VuZGFyeSwgYnV0IGl0IHN0aWxsIG5lZWRzIHRvIGJlIGNsYXJpZmllZCB3aGV0aGVyIGl0IGlz IHRoZSBjdXN0b21lcidzIG9yIFNQJ3MgQVMgbnVtYmVyLiAgQWN0dWFsbHkgZ2l2ZW4gdGhhdCB0 aGUgbW9kZWwgaXMgb25seSBjb3ZlcmluZyB3aGF0IHRoZSBjdXN0b21lciByZXF1ZXN0cywgSSBn dWVzcyBpdCB3b3VsZCBhbHdheXMgYmUgdGhlIGN1c3RvbWVyJ3MgQVMgbnVtYmVyIChzaW5jZSB0 aGUgY3VzdG9tZXIgd291bGRuJ3QgbmVlZCB0byByZXF1ZXN0IHRoZSBTUCdzIEFTIG51bWJlciwg dGhhdCB3b3VsZCBiZSBwcm92aWRlZCBieSB0aGUgU1AgdG8gdGhlIGN1c3RvbWVyLCB3aGljaCBp cyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgbW9kZWwpLiAgU28gSSB0aGluayB0aGUgdGV4dCBz aG91bGQgY2xhcmlmeSB0aGF0IHRoaXMgaXMgdGhlIGN1c3RvbWVyJ3MgQVMgbnVtYmVyLg0KICAg ICAgICAgICAgICAgIFtRaW5dIE5vdCBzdXJlIHdlIHNob3VsZCBkaXN0aW5jdCB0aGUgcGFyYW1l dGVyIHVzZWQgYnkgY3VzdG9tZXIgdG8gdGFsayB0byBwcm92aWRlciBmcm9tIHRoZSBwYXJhbWV0 ZXIgdXNlZCBieSBwcm92aWRlciB0byB0YWxrIHRvIGN1c3RvbWVyLiBJbiBUaGVvcnksIGJvdGgg Y3VzdG9tZXIgYW5kIHByb3ZpZGVyIGNhbiB1c2UgdGhpcyBtb2RlbCAgICBwYXJhbWV0ZXIgdG8g dGFsayB0byBlYWNoIG90aGVyLiBJIHdvdWxkIGxpa2UgdG8gaGVhciBvdGhlcqGvcyBvcGluaW9u Lg0KDQogICAgICogICBDb25jbHVkZWQgdGhhdCBvdGhlciBwYXJhbWV0ZXJzICh0aW1lcnMgZXRj KSBhcmUgc2V0IGJ5IHRoZSBTUCBhbmQgY29tbXVuaWNhdGVkIG91dHNpZGUgb2YgdGhlIG1vZGVs LCBub3QgcmVxdWVzdGVkIGJ5IHRoZSBjdXN0b21lci4gIE5lZWQgdG8gZXhwbGFpbiB0aGlzIGlu IHRoZSB0ZXh0Lg0KICAgICAgICAgICAgICAgICAgW1Fpbl06IE9rYXkuDQoNCiAgICAgKiAgIE51 bWJlciBvZiBCR1Agc2Vzc2lvbnMgLSBTUCBkZWNpZGVzIGFuZCB0ZWxscyB0aGUgY3VzdG9tZXIs IHNvIHRoaXMgaXMgb3V0c2lkZSB0aGUgc2NvcGUuICBOZWVkIHRvIGNsYXJpZnkgaW4gdGhlIHRl eHQuDQogICAgICAgICAgICAgIFtRaW5dOiBXaWxsIGNoZWNrIHRoaXMuDQoNCiAgICAgKiAgIE1v ZGVsIGRvZXMgbm90IGNvdmVyIHRoZSBjYXNlIG9mIGVCR1AgbXVsdGlob3AgYmV0d2VlbiBsb29w YmFja3MgLSBuZWVkIHRvIG1lbnRpb24gdGhpcyBpbiB0aGUgdGV4dC4NCiAgICAgICAgICBbUWlu XTogSSBhbSBub3Qgc3VyZSB3ZSBzaG91bGQgZW51bWVyYXRlIGFsbCB0aGUgY2FzZXMgdGhlIG1v ZGVsIGRvZXNuoa90IHN1cHBvcnQuIEl0IGlzIG5vLWVuZGluZy4gVGhpcyBtb2RlbCBpcyBqdXN0 IGEgYmFzZSBtb2RlbC4NCg0KICAgICAqICAgQWdyZWVkIG5vIGNoYW5nZSBuZWVkZWQNCiAgMS4g IEkgZGlkbid0IHNlZSBhbiBhbnN3ZXIgZnJvbSBhbnlvbmUgb24gd2h5IHRoZSBCRkQgcGFyYW1l dGVycyBjYW4gb25seSBiZSBzcGVjaWZpZWQgcGVyIGFjY2VzcyBsaW5rLiAgSXQgc2VlbXMgdXNl ZnVsIHRvIG1lIHRvIGFsbG93IHRoZW0gdG8gYmUgc3BlY2lmaWVkIHBlciBzaXRlIHRvbywgbGlr ZSBtYW55IG90aGVyIGF0dHJpYnV0ZXMuDQpbUWluXTogUGxlYXNlIHByb3ZpZGUgeW91ciB1c2Ug Y2FzZS4gTm90IHN1cmUgd2Ugc2hvdWxkIGFkZCB0aGlzLiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYg dGhlcmUgaXMgYSByZWFsIHVzZSBjYXNlLCBpdCBjYW4gYmUgYWRkZWQgdGhyb3VnaCBhdWdtZW50 YXRpb24uDQoNCiAgMS4gIENvbm5lY3Rpb24gQWRkcmVzc2luZzoNCiAgICAgKiAgIEkgc2F3IHlv dSBhZGRlZCB0aGUgcHJvdmlkZXIgYWRkcmVzcyBhbmQgbWFzayB0byB0aGUgbW9kZWwgZm9yIHRo ZSBESENQIGFuZCBESENQIHJlbGF5IGNhc2VzIC0gYnV0IGlmIHRoZSBtb2RlbCBpcyBvbmx5IGNv dmVyaW5nIGluZm9ybWF0aW9uIHJlcXVlc3RlZCBieSB0aGUgY3VzdG9tZXIsIHRoZW4gdGhpcyBk b2Vzbid0IHNlZW0gcmlnaHQuICBJbnN0ZWFkLCB0aGUgdGV4dCBzaG91bGQgZXhwbGFpbiB0aGF0 IHRoZXkgYXJlIHN1cHBsaWVkIGJ5IHRoZSBTUCBhbmQgdGh1cyBhcmUgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhlIG1vZGVsLg0KICAgICAgICAgICAgIFtRaW5dOiBZb3Ugc2V0IGEgcGl0ZmFsbCBm b3IgdXMgdG8ganVtcCw6KSwgYnV0IEkgaGF2ZSBjbGFyaWZpZWQgdGhpcyB0byB5b3UgYXQgdGhl IGJlZ2lubmluZy4gSSB3b3VsZCBsaWtlIHRvIGhlYXIgd2hhdCBMM1NNIERlc2lnbiBUZWFtIHRo aW5rIGFib3V0IHRoaXM/DQoNCiAgICAgKiAgIEFkZHJlc3NlZCBpbiB0aGUgbmV3IGRyYWZ0IC0g Y3VzdG9tZXIgY2FuIHJlcXVlc3QgZWl0aGVyIGEgbnVtYmVyIG9mIGFkZHJlc3NlcyBvciBhbiBl eHBsaWNpdCBsaXN0IG9mIGFkZHJlc3MgcmFuZ2VzLg0KICAgICAqICAgQWdyZWVkIG5vIGNoYW5n ZSBuZWVkZWQNCiAgICAgKiAgIEkgc2F3IHlvdSBhZGRlZCBhIGxlYWYgZm9yIHRoaXMsIGJ1dCBJ J20gbm90IHN1cmUgdGhhdCdzIHF1aXRlIHJpZ2h0LiAgSSdtIG5vdCBhbiBJUHY2IGV4cGVydCwg YnV0IEkgdGhvdWdodCBMTCBhZGRyZXNzZXMgYXJlIGFsd2F5cyB0aGVyZTsgbXkgcXVlc3Rpb24g d2FzIG5vdCAiTEwgYWRkcmVzc2VzIG9yIGdsb2JhbCBhZGRyZXNzZXM/IiwgaXQgd2FzICJMTCBh ZGRyZXNzZXMgb25seSwgb3IgYm90aCBMTCBhbmQgZ2xvYmFsIGFkZHJlc3Nlcz8iLiAgSWYgaXQn cyBMTCBvbmx5LCB0aGVuIEkgZG9uJ3QgdGhpbmsgYW55IG9mIHRoZSBvdGhlciBvcHRpb25zIGFw cGx5IC0gdGhlcmUgaXMgbm8gbmVlZCBmb3Igc3RhdGljIGFkZHJlc3NlcywgREhDUCBvciBTTEFB QyBpZiB0aGUgbGluayBvbmx5IHVzZXMgTEwgYWRkcmVzc2VzLg0KICAgICAgIFtRaW5dOm5vdCBz dXJlIG9uZSBhZGRyZXNzIGNhbiBiZSBib3RoIExMIGFuZCBnbG9iYWwgYWRkcmVzcyBhdCB0aGUg c2FtZSB0aW1lLCBJIHdvdWxkIHN1Z2dlc3QgdG8gcmVtb3ZlIHRoaXMgcGFyYW1ldGVyIGlmIHRo aXMgaW50cm9kdWNlIGNvbmZ1c2lvbi4NCg0KICAxLiAgS2VuaWNoaSBhZ3JlZWQgdGhlcmUgaXMg YW4gaXNzdWUgaGVyZSwgYnV0IEkgZGlkbid0IHNlZSBhbnkgZml4IGluIHRoZSBuZXcgZHJhZnQ/ DQogICAgW1Fpbl06IEl0IGlzIGxlZnQgb3ZlciBhbmQgd2lsbCBmaXggdGhpcy4NCg0KICAxLiAg Tm90IHN1cmUgd2UgcmVhY2hlZCBhIGNvbmNsdXNpb24gb24gdGhpcyBvbmUuLi4NCg0KICBbUWlu XTogTWV0cmljIGRlZmluZWQgaW4gdGhpcyBtb2RlbCBpcyB1c2VkIGZvciByb3V0aW5nIHN0YXRl IGNhbGN1bGF0aW9uIGFuZCBwYXRoIHNlbGVjdGlvbiB3aGlsZSBhY2Nlc3MgcHJpb3JpdHkgZGVm aW5lcyBkZWZpbmVzIGEgcHJlZmVyZW5jZSBmb3IgYSBwYXJ0aWN1bGFyIGFjY2VzcyBhbmQgZGVj aWRlIHByaW1hcnkvYmFja3VwIG9yIGxvYWRiYWxhbmNpbmcgcmVsYXRpb25zaGlwIGJldHdlZW4g bmV0d29yayBhY2Nlc3NlcywgdGhleSBzZXJ2ZSBkaWZmZXJlbmNlIHB1cnBvc2UsIGRvbqGvdCBt aXggdGhlbS4NCg0KVGhhbmtzLA0KDQoNCg0KICAgIERhdmlkDQoNCk9uIDAzLzA3LzIwMTcgMTA6 NTIsIFFpbiBXdSB3cm90ZToNCkhpLCBBbGw6DQpUaGUgdi0oMDIpIG9mIFJGQzgwNDliaXMgaGFz IGp1c3QgYmVlbiBwb3N0ZWQsDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXd1LWwzc20tcmZjODA0OWJpcy8NCnRoYW5rcyBKYW4gYW5kIERhdmlkIGZvciB2YWx1YWJs ZSBjb21tZW50cyBhbmQgaW5wdXQsIHRoZSBtYWluIGNoYW5nZXMgaW5jbHVkZToNCjEuU3BlY2lm eSB3aGF0IHR5cGUgb2YgSVB2NiBhZGRyZXNzIGluIHRoZSBtb2RlbCBmb3IgSVB2NiBjb25uZWN0 aW9uPyBsaW5rLWxvY2FsIGdsb2JhbA0KMi5TcGVjaWZ5IHByb3ZpZGVyIGFkZHJlc3MgYW5kIGEg bGlzdCBvZiBzdGFydC1lbmQgYWRkcmVzc2VzIGZyb20gcHJvdmlkZXIgYWRkcmVzcw0KMy5yZW1v dmUgcmVkdW5kYW50IHBhcmFtZXRlcnMgc3VjaCBhcyBkZW55LWFueS1leGNlcHQgYW5kIHBlcm1p dC1hbnktZXhjZXB0IHVuZGVyIGNsb3VkLWFjY2Vzcz8NCjQuIEFkZCBhIGZldyB0ZXh0IHRvIGNs YXJpZnkgd2hhdCB0aGUgc2l0ZSBpcyBpbiBzZWN0aW9uIDYuMw0KNS4gQWRkIGEgZmV3IHRleHQg dG8gY2xhcmlmeSB3aHkgaGF2aW5nIGN1c3RvbWVyLW5hbWUuDQo2LiBGaXhlZCB0d28gdHlwb3Mg cG9pbnRlZCBieSBKYW4gcmVjZW50bHkuDQoNClRhbGtpbmcgd2l0aCBMM1NtIGRlc2lnbiB0ZWFt LCB3ZSBiZWxpZXZlIGhvdyBpbmZvcm1hdGlvbiBpcyBjb21tdW5pY2F0ZWQgYnkgU1AgdG8gdGhl IGN1c3RvbWVyIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YNClJGQzgwNDkgaGFzIGFscmVhZHkgYmVl biBjbGFyaWZpZWQgaW4gc2VjdGlvbiA2LjYsIDJuZCBwYXJhZ3JhcGgsIHNlY3Rpb24gNi42LjMs Mm5kIHBhcmFncmFwaCwgMXN0IGJ1bGxldCwgM3JkIGJ1bGxldCwgc2VjdGlvbiA2LjEyLjIuMiw0 dGggcGFyYWdyYXBoLg0KDQpSZWdhcmRpbmcgd2hldGhlciBBUyBudW1iZXIgdW5kZXIgQkdQIHBy b3RvY29sIGlzIHN1cHBvc2VkIHRvIGJlIHRoZSBjdXN0b21lcidzIEFTIG51bWJlciBvciB0aGUg U1AncyBBUyBudW1iZXIsIHdlIHRoaW5rIEFTIG51bWJlciBhcw0KcGFydCBvZiBCR1AgcHJvdG9j b2wgcmVsYXRlZCBwYXJhbWV0ZXJzIGFyZSBhcHBsaWVkIHRvIHByb3ZpZGVyIHRvIGN1c3RvbWVy IGJvdW5kYXJ5LCB0aGVyZWZvcmUgdGhlIGFuc3dlciBpcyBkZXBlbmRpbmcgb24NCmhvdyB0aGUg bWFuYWdlbWVudCBtb2RlbCBpcyBhZG1pbmlzdGVyZWQuDQoNCkFzIEphbiBwb2ludGVkIG91dCwg d2Ugc3RpbGwgaGF2ZSBzb21lIG5ldyBtYW5kYXRvcnkgZmllbGRzIGludHJvZHVjZWQgaW4gdi0o MDIpIGhhdmVuoa90IGJlZW4gcmVmbGVjdGVkIGluIHRoZSBleGFtcGxlcy4gQnV0IGhlIGlzIG9r YXkgd2l0aCB0aGUgY3VycmVudCBzaGFwZS4NClBsZWFzZSByZXZpZXcgdGhlc2UgY2hhbmdlcywg bGV0IHVzIGtub3cgaWYgdGhlcmUgaXMgYW55IGFkZGl0aW9uYWwgY29tbWVudHMuDQoNClJlZ2Fy ZHMhDQpRaW4gKG9uIGJlaGFsZiBvZiB0ZWFtKQ0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KTDNzbSBtYWlsaW5nIGxpc3QNCg0K TDNzbUBpZXRmLm9yZzxtYWlsdG86TDNzbUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQoNCg0KDQotLQ0KDQpEYXZpZCBCYWxsDQoNCjxkYXZp YmFsbEBjaXNjby5jb20+PG1haWx0bzpkYXZpYmFsbEBjaXNjby5jb20+DQo= --_000_B8F9A780D330094D99AF023C5877DABA9A9A7FBDnkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

=B7=A2= =BC=FE=C8=CB: David B= all [mailto:daviball@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo= r:windowtext"> 2017=C4=EA7=D4=C25=C8=D5 19:47
=CA=D5=BC=FE=C8=CB: Qin Wu; l3sm@ietf.org; l2sm@ietf.org
=B3=AD=CB=CD: Benoit Claise (bclaise); adrian@olddog.co.uk
=D6=F7=CC=E2: Re: [L3sm] Followup of RFC8049bis

 

Thanks Qin.

I thought it might be useful to summarize the discu= ssion on each of my original questions so far.  In general, I imagine = that if I had a question, other readers might have the same question too, s= o even if we have answered the question on the thread, I think it is good to provide the clarification in the text= as well.

  1. You mention below that you think this is already descr= ibed in section 6.6 and 6.12.  However, the fact that the model only c= overs information requested by the customer to the SP is a key aspect of th= e model that is critical to the reader's understanding, so I think it needs to be explained much more clearly, and = much earlier in the document i.e. in section 5.

   &nb= sp;  [Qin]: You need to read carefully, it clearly explain what kind o= f information responded by SP to the Customer is not in the scope of this document. For most of other information, it doesn=A1=AFt require S= P to respond back to Customer.

See section 6.6 , 3rd paragraph:

=A1=B0If a constraint= is too strict and cannot be fulfilled, the management system MUST NOT prov= ision the site and SHOULD provide relevant information to the user.=A1=B1

See section 6.6.3 2nd paragraph ,1st bullet:

=A1=B0If the "st= rict" leaf is equal to "false"(default) and if the requested= media type cannot be fulfilled, the management system can select another media type.  The supported media types SHOULD be communicated= by the SP to the customer via a mechanism that is out of scope for this do= cument.=A1=B1

See section 6.12.2.2,= 4th paragraph:

=A1=B0some constraint= s may not be completely fulfilled by the SP; in this case, the SP should ad= vise the customer about the limitations.  How this communication is done is out of scope for this document.=A1=B1

  1. As far as I saw, you only added one sentence about thi= s - I think a bit more is needed!  In fact I wonder if we are even all= on the same page in the emails, since your answer didn't seem to quite ali= gn with what Kenichi and Stephane said.

[Qin]: Site notion ha= s been well clarified in the document:

=A1=B0   A site has several characteristics:

 

   o  Unique identifier (site-id): uniquely ident= ifies the site within

      the overall network infrastructur= e.  The identifier is a string

      that allows any encoding for the = local administration of the VPN

      service.

 

   o  Locations (locations): site location inform= ation that allows easy

      retrieval of information from the= nearest available resources.  A

      site may be composed of multiple = locations.

 

   o  Devices (devices): allows the customer to r= equest one or more

      customer premises equipment entit= ies from the SP for a particular

      site.

 

   o  Management (management): defines the type o= f management for the

      site -- for example, co-managed, = customer-managed, or provider-

      managed.  See Section 6.10.

 

   o  Site network accesses (site-network-accesse= s): defines the list of

      network accesses associated with = the sites, and their properties

      -- especially bearer, connection,= and service parameters.

=A1=B1

I add one sentence to= get consist with this. The proposed changes have got approved by Stepane a= nd Kenichi already before posting to the list.

  1. I didn't see any text added to address this - and agai= n, I'm not sure we're all on the same page yet.  Kenichi agreed that t= here is no technical difference between using SubVPN and using multiple sit= es, although obviously this is related to question 2.  At the very least, the ambiguity in the existing text= should be fixed!

[Qin]:I think the key= difference between subVPN and multi-VPN is whether they share the same bea= rer. It is clarified in the section 6.5.1.3

=A1=B0

It is similar to having separate sites, but in this case the cus= tomer

wants to share some physical components while maintaining strong= communication isolation between the affiliates.

=A1=B1

Physical components a= re referred to the bearer.

I think this is suffi= cient. If you think we should further limit subVPN to the same bearer and s= ame CPE, please let me know.

  1. Addressed in the new draft
  2. Conclusion is that using a single VPN service for mult= iple clouds is technically the same as using a separate VPN service for eac= h cloud, but it might be easier operationally.  This needs to be expla= ined in the draft.

[Qin]: I believe usin= g a separate VPN service for each cloud is not in the scope of this documen= t. This draft clear explained to support public cloud access, support private cloud access with a single VPN servic= e.

  1. Addressed in the new draft
  2. Can be addressed with an augment, so no change needed<= o:p>
[Qin]: Agr=
ee, do you think section 6.1 =A1=B0Features and Augmentation=A1=B1 is suffi=
cient to address your comment with any text change.<=
/o:p>
  1. You agreed to add some additional explanation about MT= U, but I didn't see any changes in the draft?

[Qin]:Addressed in th= e previous version which address Jan=A1=AFs comments, See

=A1=B0

   &nb= sp; leaf svc-mtu { 

   &nb= sp;   type uint16; 

   &nb= sp;   units bytes; 

   &nb= sp;   mandatory true; 

   &nb= sp;   description 

   &nb= sp;    "MTU at service level. If the service is IP= , 

   &nb= sp;     it refers to the IP MTU. If CsC is enabled= , 

   &nb= sp;     the requested 'svc-mtu' leaf will refer to= the 

   &nb= sp;     MPLS MTU and not to the IP MTU. ";

=A1=B1

  1. Conclusion was that max routes per VPN might be useful= but hard to implement, so no change needed.
  2. Per-VPN QoS policy can be achieved in most cases using= the target-sites option - need to add text to explain this

[Qin]: Okay.

  1. Can specify different performance objectives by using = more classes, no change needed
  2. I still don't understand what the SP is supposed to do= in a multipoint case where end-to-end is true.  Actually, even in a P= 2P case, there is a problem if the guaranteed end-to-end bandwidth is speci= fied differently at each end.  Should the SP take the higher or lower value?
[Qin]: I t=
hink this depends on the SP's implementation of the service.
  1. Routing:
    1. Agreed no change needed
    2. Agreed no change needed
    3. Concluded that other parameters (timers etc) are set b= y the SP and communicated outside of the model, not requested by the custom= er.  Need to explain this in the text.

   &nb= sp;            =     [Qin]: Okay.

    1. Addressed in the new draft
    2. I did not understand your comment about the BGP AS num= ber below - all the attributes in the model are applied at the customer to = SP boundary, but it still needs to be clarified whether it is the customer'= s or SP's AS number.  Actually given that the model is only covering what the customer requests, I guess it wou= ld always be the customer's AS number (since the customer wouldn't need to = request the SP's AS number, that would be provided by the SP to the custome= r, which is outside the scope of the model).  So I think the text should clarify that this is the cust= omer's AS number.

    &n= bsp;           [Qin]= Not sure we should distinct the parameter used by customer to talk to prov= ider from the parameter used by provider to talk to customer. In Theory, both customer and provider can use this mo= del    parameter to talk to each other. I would like to hear= other=A1=AFs opinion.

    1. Concluded that other parameters (timers etc) are set b= y the SP and communicated outside of the model, not requested by the custom= er.  Need to explain this in the text.

   &nb= sp;             = ; [Qin]: Okay.

    1. Number of BGP sessions - SP decides and tells the cust= omer, so this is outside the scope.  Need to clarify in the text.=

   &nb= sp;          [Qin]: Will check= this.

    1. Model does not cover the case of eBGP multihop between= loopbacks - need to mention this in the text.

   &nb= sp;      [Qin]: I am not sure we should enumerate = all the cases the model doesn=A1=AFt support. It is no-ending. This model i= s just a base model.

    1. Agreed no change needed
  1. I didn't see an answer from anyone on why the BFD para= meters can only be specified per access link.  It seems useful to me t= o allow them to be specified per site too, like many other attributes.=

[Qin]: Please provide your use= case. Not sure we should add this. On the other hand, if there is a real u= se case, it can be added through augmentation.

  1. Connection Addressing:
    1. I saw you added the provider address and mask to the m= odel for the DHCP and DHCP relay cases - but if the model is only covering = information requested by the customer, then this doesn't seem right.  = Instead, the text should explain that they are supplied by the SP and thus are outside the scope of the model.

   &nb= sp;         [Qin]: You set a pitfal= l for us to jump,J, but I have clarified this to you at the beginning. I would like to hear wh= at L3SM Design Team think about this?

    1. Addressed in the new draft - customer can request eith= er a number of addresses or an explicit list of address ranges.<= /span>
    2. Agreed no change needed
    3. I saw you added a leaf for this, but I'm not sure that= 's quite right.  I'm not an IPv6 expert, but I thought LL addresses ar= e always there; my question was not "LL addresses or global addresses?= ", it was "LL addresses only, or both LL and global addresses?".  If it's LL only, then I don't think any of = the other options apply - there is no need for static addresses, DHCP or SL= AAC if the link only uses LL addresses.

   &nb= sp;   [Qin]:not sure one address can be both LL and global addres= s at the same time, I would suggest to remove this parameter if this introd= uce confusion.

  1. Kenichi agreed there is an issue here, but I didn't se= e any fix in the new draft?

    [Q= in]: It is left over and will fix this.

  1. Not sure we reached a conclusion on this one...
  [Qin]: Metric defined in this model is used for routing state=
 calculation and path selection while access priority defines defines a pre=
ference for a particular access and decide primary/backup or loadbalancing =
relationship between network accesses, they serve difference purpose, don=
=A1=AFt mix them.

Thanks,

 

    David

 

On 03/07/2017 10:52, Qin Wu wro= te:

Hi, All:

The v-(02) of RFC8049bis has ju= st been posted,

https://datatracker.ietf.org/doc= /draft-wu-l3sm-rfc8049bis/

thanks Jan and David for valuab= le comments and input, the main changes include:

1.Specify what type of IPv6 address in the model for IPv6 connec= tion? link-local global

2.Specify provider address and a list of start-end addresses fro= m provider address

3.remove redundant parameters such as deny-any-except and permit= -any-except under cloud-access?

4. Add a few text to clarify wh= at the site is in section 6.3

5. Add a few text to clarify wh= y having customer-name.

6. Fixed two typos pointed by J= an recently.

 

Talking with L3Sm design team, = we believe how information is communicated by SP to the customer is beyond = the scope of

RFC8049 has already been clarified in section 6.6, 2nd= paragraph, section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section 6.= 12.2.2,4th paragraph.

 

Regarding whether AS number und= er BGP protocol is supposed to be the customer's AS number or the SP's AS n= umber, we think AS number as

part of BGP protocol related pa= rameters are applied to provider to customer boundary, therefore the answer= is depending on

how the management model is administered.

 

As Jan pointed out, we still have some new mandatory f= ields introduced in v-(02) haven=A1=AFt been reflected in the examples. But= he is okay with the current shape.

Please review these changes, let us know if there is a= ny additional comments.

 

Regards!

Qin (on behalf of team)

 

 




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




-- 
David Ball
<davibal=
l@cisco.com>
--_000_B8F9A780D330094D99AF023C5877DABA9A9A7FBDnkgeml513mbxchi_-- From nobody Mon Jul 31 01:33:49 2017 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FD7131F23; Mon, 31 Jul 2017 01:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 7K5qJVRhWb-s; Mon, 31 Jul 2017 01:33:46 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447F1131F1F; Mon, 31 Jul 2017 01:33:42 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v6V8XeT6011153; Mon, 31 Jul 2017 09:33:40 +0100 Received: from 950129200 (115x125x248x66.ap115.ftth.ucom.ne.jp [115.125.248.66]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v6V8XaPo011110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jul 2017 09:33:39 +0100 Reply-To: From: "Adrian Farrel" To: Cc: Date: Mon, 31 Jul 2017 09:33:36 +0100 Message-ID: <03d501d309d7$b6260540$22720fc0$@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: AdMJ167t+iU2cx/0Q9GqyfNE2LTmRw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23228.006 X-TM-AS-Result: No--7.797-10.0-31-10 X-imss-scan-details: No--7.797-10.0-31-10 X-TMASE-MatchedRID: yKZMM4OYzktdpLkh5p97g0hEDfw/93BunbR1KGab5XmYoidDrWJoA/il vb96zcbIRXOC9GJIR1d8WIPdTACsQQldMc3Hj8/ox0PDBzN98K7C4hYi9ARtbt9zZd3pUn7K876 azl5+m3vi8zVgXoAltlwtzewu2M63qmev5eeaIQNq8/xv2Um1avoLR4+zsDTtyMdyHKes7ltn6s yi0/jAdbYVREJ7sND9sslhzrQ7JasUubKFHA0CFA== Archived-At: Subject: [L2sm] Early heads-up on an L2SM virtual interim X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 08:33:48 -0000 Hi, We are in the early stages of planning a virtual interim to advance the L2SM document. There is no way we could find a date and time that is convenient for you all, but we hope that by giving advance warning as many of you as possible will be able to attend. Date: Wednesday 27th September Time: 2pm UK We'll work with Giuseppe (document editor) to build an agenda, but it will basically be, "Close all the open issues and check there are no more issues." Cheers, Adrian