From nobody Wed Feb 3 13:17:22 2016 Return-Path: X-Original-To: l3sm@ietf.org Delivered-To: l3sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DEA1B2BFE; Wed, 3 Feb 2016 13:17:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203211719.16779.63089.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 13:17:19 -0800 Archived-At: Cc: l3sm@ietf.org Subject: [L3sm] L3SM WG Virtual Interim Meeting: February 25, 2016 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 21:17:19 -0000 The L3VPN Service Model (L3SM) working group will hold a virtual interim meeting on Thursday 25th February at 8am New York (2pm Paris). The meeting will last for 2 hours and will be held on Webex. The purpose of the meeting will be to attempt to reach closure on *all* remaining open issues on draft-ietf-l3sm-l3vpn-service-model as tracked on the working group's wiki and recently discussed on the mailing list. A more detailed agenda and Webex details will be sent out before the meeting. From nobody Sun Feb 7 10:04:37 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B15A1A0334 for ; Sun, 7 Feb 2016 10:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.301 X-Spam-Level: X-Spam-Status: No, score=-8.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 TcCiMimcg1mh for ; Sun, 7 Feb 2016 10:04:35 -0800 (PST) Received: from sjmda14.webex.com (sjmda14.webex.com [64.68.124.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F48E1A033A for ; Sun, 7 Feb 2016 10:04:33 -0800 (PST) Received: from jva2tc215.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-3.webex.com [64.68.121.238]) by sjmda14.webex.com (Postfix) with ESMTP id 07A14821EB for ; Sun, 7 Feb 2016 18:04:33 +0000 (GMT) Received: from jva2tc215.webex.com (localhost [127.0.0.1]) by jva2tc215.webex.com (Postfix) with ESMTP id BF60CC6 for ; Sun, 7 Feb 2016 18:04:32 +0000 (GMT) Date: Sun, 7 Feb 2016 18:04:32 +0000 (GMT) From: L3SM Working Group To: l3sm@ietf.org Message-ID: <116165926.93644.1454868272781.JavaMail.nobody@jva2tc215.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_93642_928397062.1454868272780" X-Priority: 3 Importance: normal Archived-At: Subject: [L3sm] WebEx meeting invitation: L3SM Virtual Interim X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: l3sm-chairs@ietf.org List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 18:04:36 -0000 ------=_Part_93642_928397062.1454868272780 Content-Type: multipart/Alternative; boundary="----=_Part_93643_2100725579.1454868272780" ------=_Part_93643_2100725579.1454868272780 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTDNTTSBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJF eCBtZWV0aW5nLgoKCkwzU00gVmlydHVhbCBJbnRlcmltClRodXJzZGF5LCBGZWJydWFyeSAyNSwg MjAxNgo4OjAwIGFtICB8ICBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUgKE5ldyBZb3JrLCBHTVQtMDU6 MDApICB8ICAyIGhycwoKCkpPSU4gV0VCRVggTUVFVElORwpodHRwczovL2lldGYud2ViZXguY29t L2lldGYvai5waHA/TVRJRD1tZTQ5NDRjNzdhNThhM2Q5OWM0MjBiOGVhOGIyNzUyZWIKTWVldGlu ZyBudW1iZXI6IDY0MSA0MjEgNDM4Ck1lZXRpbmcgcGFzc3dvcmQ6IDEyMzQKCg0KSk9JTiBCWSBQ SE9ORQ0KMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEp IAoxLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpCkFjY2VzcyBj b2RlOiA2NDEgNDIxIDQzOAoKVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiAKaHR0cDov L3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYNCg0KCkFkZCB0aGlz IG1lZXRpbmcgdG8geW91ciBjYWxlbmRhciAoQ2Fubm90IGFkZCBmcm9tIG1vYmlsZSBkZXZpY2Vz KToKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTZiOTYxY2NiNzljM2M0 OWUyYzdmNWFhMjZmMjY0NDM3DQoNCgpDYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1 cHBvcnQgaGVyZToKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jCgoKSU1QT1JUQU5UIE5P VElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFu ZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRl ZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmlu ZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRp bmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91 ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLgo= ------=_Part_93643_2100725579.1454868272780 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBMM1NN IFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYkV4IG1lZXRpbmcuCiAg ICAgICAgICAgICAgICAJICAgICAgICAgICA8L3RkPgogICAgICA8L3RyPgo8L3RhYmxlPgoKCgoK PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoy MHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlICB3aWR0aD0iMTAwJSI+ CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTZweDsgY29sb3I6IzRE NEQ0RCI+CgkJCQkJCQkJCTxiPkwzU00gVmlydHVhbCBJbnRlcmltPC9iPgoJCQkJCQkJCTwvdGQ+ CgkJCQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+ VGh1cnNkYXksIEZlYnJ1YXJ5IDI1LCAyMDE2CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJ CQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD44OjAwIGFtJm5ic3A7Jm5i c3A7fCZuYnNwOyZuYnNwO0Vhc3Rlcm4gU3RhbmRhcmQgVGltZSAoTmV3IFlvcmssIEdNVC0wNTow MCkmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MiBocnMKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90 cj4KCQkJCQkJPC90YWJsZT4KCjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+ PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0 YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRy PgoJCQkJCQkJCTx0ZCBzdHlsZT0iY29sb3I6IzAwQUZGOTtmb250LXNpemU6MTZweCI+CgkJCQkJ CQkJCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1lNDk0 NGM3N2E1OGEzZDk5YzQyMGI4ZWE4YjI3NTJlYiIKCQkJCQkJCQkJCXN0eWxlPSJ0ZXh0LWRlY29y YXRpb246bm9uZTtmb250LXNpemU6MTZweDtjb2xvcjojMDBBRkY5Ij4KCQkJCQkJCQkJCTxiPkpv aW4gV2ViRXggbWVldGluZzwvYj4KCQkJCQkJCQkJPC9hPgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8 L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRo OmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJ PHRkIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij4KCQkJCQkJCQkJTWVldGluZyBudW1iZXI6 CgkJCQkJCQkJPC90ZD4KCQkJCQkJCQk8dGQ+NjQxIDQyMSA0MzgKCQkJCQkJCQk8L3RkPgoJCQkJ CQkJPC90cj4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVw eDsiPk1lZXRpbmcgcGFzc3dvcmQ6PC90ZD4KCQkJCQkJCQk8dGQ+MTIzNDwvdGQ+CgkJCQkJCQk8 L3RyPgoJCQkJCQk8L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6 MjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRh YmxlPjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTg3Ny02NjgtNDQ5MzwvYj4m bmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0 eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8L2I+Jm5ic3A7Q2FsbC1pbiB0 b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0 ZD5BY2Nlc3MgY29kZTombmJzcDs2NDEgNDIxIDQzODwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdp bjowcHgiPjx0ZD48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVz dHJpY3Rpb25zLnBkZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4 O2NvbG9yOiMwMEFGRjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L2E+PC90ZD48 L3RyPjwvdGFibGU+CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0 ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+ PHRkIHN0eWxlPSJmb250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTZiOTYxY2NiNzljM2M0OWUyYzdmNWFhMjZmMjY0NDM3IiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOTsgZm9udC1zaXplOjEzcHgiPkFk ZCB0aGlzIG1lZXRpbmc8L2E+IHRvIHlvdXIgY2FsZW5kYXIuIChDYW5ub3QgYWRkIGZyb20gbW9i aWxlIGRldmljZXMuKTwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3Rh YmxlPgo8dGFibGU+CiAgICA8dHI+CiAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDtm b250LWZhbWlseTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7Ij4KICAgICAgICBDYW4ndCBqb2luIHRo ZSBtZWV0aW5nPwogICAgIAk8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMi IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTNweDtmb250LWZhbWlseTpB cmlhbDtjb2xvcjojMDBBRkY5O2ZvbnQtY29sb3I6IzAwQUZGOTsiPgogICAgICAgIAlDb250YWN0 IHN1cHBvcnQuPC9hPgoJCTwvdGQ+CiAgICA8L3RyPgo8L3RhYmxlPgo8dGFibGU+PHRyIHN0eWxl PSJsaW5lLWhlaWdodDogMTBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjEwcHgiPiZuYnNwOzwvdGQ+ PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGU+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxl PSJmb250LXNpemU6MTJweDtjb2xvcjogI0EwQTBBMDsiPgoJCQkJCQkJCQlJTVBPUlRBTlQgTk9U SUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5k IG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVk LCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5n IHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGlu Z3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3Vy IGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPC90ZD4K CQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+CgkJCQk8L3RkPgoJCQk8L3RyPgoJCTwvdGFibGU+ Cgk8L3RkPgogICA8L3RyPgo8L3RhYmxlPgoKPC9ib2R5Pg== ------=_Part_93643_2100725579.1454868272780-- ------=_Part_93642_928397062.1454868272780 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE0MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE0MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86bDNzbUBpZXRmLm9yZwpPUkdBTklaRVI7Q049Ikwz U00gV29ya2luZyBHcm91cCI6TUFJTFRPOmwzc20tY2hhaXJzQGlldGYub3JnCkRUU1RBUlQ7VFpJ RD0iRWFzdGVybiBUaW1lIjoyMDE2MDIyNVQwODAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVybiBUaW1l IjoyMDE2MDIyNVQxMDAwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmClRS QU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQ1NDg2ODI3MgpVSUQ6MGNmZmEzOTMtMjIwOC00MDM4LTkx ZmItYzdmOTlhZDc3ZDYzCkRUU1RBTVA6MjAxNjAyMjVUMTMwMDAwWgpERVNDUklQVElPTjpcblxu XG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW02NzY5ZTQ1MjI1N2FjM2YwNDZlYmNiNWYzNTgwYTg2YlxuTWVldGluZyBudW1iZXI6IDY0 MSA0MjEgNDM4XG5NZWV0aW5nIHBhc3N3b3JkOiAxMjM0XG5cblxuSk9JTiBCWSBQSE9ORVxuMS04 NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIFxuMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuQWNjZXNzIGNvZGU6IDY0 MSA0MjEgNDM4XG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogXG5odHRwOi8vd3d3 LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2FuJ3Qgam9p biB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMg V2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVy aW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxl IGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRp Y2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0 byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3Ig ZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDoJ PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZPTlQgU0laRT0iNCIgRkFD RT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW02NzY5ZTQ1MjI1N2FjM2YwNDZlYmNiNWYzNTgwYTg2YiI+PEZPTlQgU0laRT0iMyIg Q09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1lZXRpbmc8L0ZPTlQ+PC9h PgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05UPgkJCQkJPC90ZD4JCQkJ CTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjY0 MSA0MjEgNDM4PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0YWJsZT48 dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGlu ZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+MTIzNDwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4JCTwvRk9OVD48Rk9O VCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+PEZPTlQg U0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTg3Ny02NjgtNDQ5Mzwvc3Ryb25n PiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsg PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4x LTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPkFjY2VzcyBjb2RlOiA2NDEgNDIxIDQzODwvRk9OVD4mbmJzcDsgPEJSPjxhIGhyZWY9 Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIj48Rk9O VCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPlRvbGwtZnJlZSBjYWxsaW5n IHJlc3RyaWN0aW9uczwvRk9OVD48L2E+ICZuYnNwOyA8QlI+PC9GT05UPjxCUj48QlI+CSZuYnNw OzxCUj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj4JCQkJQ2Fu J3Qgam9pbiB0aGUgbWVldGluZz88L0ZPTlQ+CTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9tYyI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+ Q29udGFjdCBzdXBwb3J0LjwvRk9OVD48L2E+CSZuYnNwOzxCUj4mbmJzcDs8QlI+PEZPTlQgQ09M T1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVh c2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBt YXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vz c2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlv dSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5z IHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPC9GT05UPjwvRk9OVD4K U1VNTUFSWTpMM1NNIFZpcnR1YWwgSW50ZXJpbQpQUklPUklUWTo1CkNMQVNTOlBVQkxJQwpCRUdJ TjpWQUxBUk0KVFJJR0dFUjotUFQxNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJT046UmVtaW5k ZXIKRU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK ------=_Part_93642_928397062.1454868272780-- From nobody Wed Feb 17 17:18:50 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507BE1B31B7 for ; Wed, 17 Feb 2016 17:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.894 X-Spam-Level: X-Spam-Status: No, score=0.894 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham 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 MoANhxVDSlT4 for ; Wed, 17 Feb 2016 17:18:36 -0800 (PST) Received: from post-send.kddi.com (athena4.kddi.com [27.90.165.197]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6461B31B2 for ; Wed, 17 Feb 2016 17:18:36 -0800 (PST) Received: from LTMC2122.kddi.com (LTMC2122.kddi.com [10.206.0.63]) by post-send.kddi.com (KDDI Mail) with ESMTP id BCD081200C7 for ; Thu, 18 Feb 2016 10:18:35 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2122.kddi.com with ESMTP; Thu, 18 Feb 2016 10:18:35 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 8E7FB4C005A for ; Thu, 18 Feb 2016 10:18:35 +0900 (JST) Received: from LTMC2151.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id 7F2494C0058 for ; Thu, 18 Feb 2016 10:18:35 +0900 (JST) Received: from LTMC2151.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u1I1IYha006317 for ; Thu, 18 Feb 2016 10:18:35 +0900 Received: from LTMC2151.kddi.com.mid_32171083 (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u1I18UQZ026713 for ; Thu, 18 Feb 2016 10:08:31 +0900 X-SA-MID: 32171083 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Thu, 18 Feb 2016 10:08:30 +0900 From: "Ogaki, Kenichi" To: Date: Thu, 18 Feb 2016 10:08:30 +0900 Message-ID: <000101d169e8$e19802e0$a4c808a0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFUzU8XUm4agADpQBu6GQYzpCj8Xw== Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2016 01:18:47 -0000 Hi Stephane and All, As for issue #10 itself, the following solution can be acceptable for = us. >One proposal could be to not call this VPN policy, but creating a = container "extranet-vpn-policy" at vpn level which will mandate an = extranet=20 >VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). What model is in your mind? I can't see what ""extranet-vpn-policy" at = vpn" means. Like this? ... 1 VPN1 VPN2 ... Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Monday, December 07, 2015 11:45 PM To: Ogaki, Kenichi; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org Cc: adrian@olddog.co.uk Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session Hi Kenichi, Regarding your proposal of having a simple VPN policy in the vpn-svc = container, I do see an issue. One of the key point of the VPN policy is = to express the role of the site in the target VPN topology. If we do a vpn policy at VPN level, we cannot anymore describe site = roles in the target VPN which causes an issue. In an ideal world where all VPNs are any to any, the site role is always = the same and there is no issue, but let's think about someone trying to = use the vpn-policy (at vpn level) to connect to a Hub & Spoke VPN, how = do you deduce the roles of the sites ? One proposal could be to not call this VPN policy, but creating a = container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). This means that the usage is really limited to "simple" = extranet-vpns and it does not replace nor compete with the VPN policy at = site level. Could it be a good compromise ? Stephane -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Saturday, December 05, 2015 06:23 To: LITKOWSKI Stephane SCE/OINIS; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org Cc: adrian@olddog.co.uk Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session Dear Stephane and All, I don't say that sites *must* move under vpn-svc because I understand = stephane's use case. But we already have vpn-svc and some parameters under this are globally = applied to all the sites even in the current model. It depends on operator's use case which is site-oriented or vpn-oriented = service. Our service is vpn-oriented, site has the native VPN. Then, I would just = like you to allow other global options to vpn-svc. Thanks, Kenichi -----Original Message----- From: stephane.litkowski@orange.com = [mailto:stephane.litkowski@orange.com] Sent: Friday, December 04, 2015 8:17 PM To: Aijun Wang; 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org Cc: adrian@olddog.co.uk Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session Hi, I'm against this proposal, as I do not want to create any dependency = between a particular VPN and a list of sites. A site can belong to multiple VPNs with any kind of topology, if we = attach the site to a single VPN, we come back to the notion of "native = VPN" we had at the beginning of the model which was hard to understand = and so was removed. -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Friday, December 04, 2015 02:44 To: 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org Cc: adrian@olddog.co.uk Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session Dear all: Can we put the list "sites" within the list "vpn-svc", and define the = general vpn policy for all sites that within the corresponding vpn = service instance? If doing so, some entries within the current list "sites" can also be = dragged out for general usual purposes, for example, "maximum-routes", = "security" etc. These parameters are often all same for every site = within one VPN service instance.=20 If some sites have special requirements, we can achieve this by using = some special "site-vpn-policy" within the corresponding site definition. Is this more acceptable for customers? Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Intelligent = Network Product Line =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Friday, December 04, 2015 9:02 AM To: 'Qin Wu'; l3sm@ietf.org Cc: adrian@olddog.co.uk Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session Dear All, It was good having discussion. As for issue#10, the objective and problem we discussed in the meeting = as follows. The objective is to provide per-VPN extranet service which connects two = different VPNs (e.g. VPN1 and VPN2). It means that any sites in VPN1 can = access to any sites in VPN2. The problem is that the current model must update vpn-policy under all = the sites belong to these two VPNs in order to offer this service. = Especially when this model is used as a customer self-control API, it's = not good idea to require customers to update the information of all the = sites. (It's not abstracted way, a service model should provide what the = consumer wants, not how.) If a service or customer requires to control = per-site vpn-policy, that of current model should be used without = setting per-VPN vpn-polity. It depends on each operator's service. Stephane proposed to use apply-template, but it still cannot solve the = problem. When each VPN already has a large number of sites and want to = connect each other for the first time, both VPNs must update these sites = to apply apply-template on the current model. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu Sent: Friday, December 04, 2015 12:42 AM To: l3sm@ietf.org Cc: adrian@olddog.co.uk Subject: [L3sm] L3SM interim meeting minutes on Thursday L3SM interim = session Hi all: =20 Below is the initial version of draft minutes for Thursday L3SM WG = interim session. Thanks Dan to help take minutes. Folks, please let us know if you have any correction. =20 -Qin =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D L3SM Working Group Virtual Interim Meeting=20 Thursday December 5th, 2015. 8am East Coast Time (New York) =20 BLUE SHEET =20 Name | Affiliation ------------------------+----------------------------------------------- ------------------------+- Adrian Farrel | Old Dog Consulting Qin Wu | Huawei Technologies Stephane Litkowski | Orange Luis Tomotaki | Verizon Daniel King | Old Dog Consulting Susan Hares | Huawei Technologies Scott Mansfield | Ericsson Gu Rong | China Mobile=20 Kenichi Ogaki | KDDI Aijun Wang | China Telecom Victor Santos | Ericsson Ignas Bagdonas |=20 MINUTES =20 * Meting logiistics = https://mailarchive.ietf.org/arch/msg/l3sm/SJub1aHVQGOQW6rWhthX0fB8Ac8=20 * Meeting materials = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/proceedings.html= =20 * Etherpad for minutes (this page) = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03 * Jabber using l3sm@jabber.ietf.org * Blue sheet = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03-bluesheet =20 Agendaa - Administrivia (Note Well, etc). a - Introduction - Open Issues for YANG Data Model for L3VPNservice delivery = (draft-ietf-l3sm-l3vpn-servicemodel) o Open Issues discussion and resolution=E2=80=93 = http://trac.tools.ietf.org/wg/l3sm/trac/report/1 =20 For a full list of issues and resolution proposals please see: = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/slides/slides-in= terim-2015-l3sm-1-2.pdf =20 Issue#1: When customer-nat-address is used Resolution #1: Leaf used when NAT is required to access cloud VPN and = customer wants to use its ownIP address. If provider provides the public = IP,no need to use the leaf Status #1: Closed Pending I-D text review. =20 Discussion on #1:=20 =20 Aijun asks for more description in the YANG model itself Stephane shows current model Agreed OK =20 Issue#2 : Identify l3vpn svc using id or name or both Resolution #2: ID is a string, as per other properties in the model Status #2: Closed Discussion on #2:=20 =20 Agreed OK =20 Issue#3: M to N availability support Resolution #3: Modeling sites using a list with a priority, so include = access list with a priority. Status #3: Discussion on #3:=20 =20 Qin was asking that M to N availability is supported with access and = priority number.=20 Stephane stated this is suppoted. This new proposal also supports = multiple sites, as a list. Qin also asked if Group I-D was no longer needed, which it is not. Also = good solution supported by other operators. Stephane asked if four priorities was enough, or if more were needed.=20 =20 Re: Containers/Properties for Network Access Configuration - = Conclusions? =20 o Location - Different site I-D? o QoS Policy - Per network access link, or site information? Would QoS = (cost) be different per accesslink or site? Example of Primary and = Backup links given.=20 o Bandwidth - Moved to access link group=20 o Maximum Routes -=20 Security, routing, and services are duplicated with inheritance =20 =20 Issue#4: site-service-cloud access as grouping Resolution #4 Already resilved as a separate grouping Status #4: Closed Discussion on #4:=20 =20 Issue#5: Multicast support as raised by Eric Rosen Resolution #5: : New "provider managed" property, and in Site Properties = "property-type" added Status #5: Solution proposed.=20 Discussion on #5:=20 =20 Stephane will proviode new property proposals will be provided to Eric = for review.=20 =20 Issue#6: Inventory operational state Resolution #6: Include a new container for inventory state, or an RPC = call (sitting above the service orchestrator) to retrieve inventory = state.=20 Status #6: Need to propose to the WG and agree solution. Discussion on #6:=20 =20 Luis asked would this info be collected from provision state? Stephane = suggested this would not be availible.=20 Adrian observed that the code used to convert the model into a service = request may not utilise this inventory information capability. Sue = mentioned that others have mentioned by a vendor that it would be useful = to have the ability to configure inventory state. This should be = clarified by the operators.=20 =20 Stephane to take proposals to list and ask anyone who is interested in = having the feature to suggest text. =20 =20 Issue#7: Generic VAS - do we need to create a generic VAS container as = VAS are popular in L3VPNs? Resolution #7: Separate from L3SM Status #7: Closed Discussion on #7:=20 =20 Gu Rong highlighted Generic VAS model which was presented at IETF 94.=20 =20 Issue#8: Who keeps site locationinformation? Resolution #8: Text has been fixed Status #8: Closed Discussion on #8:=20 =20 Issue#9: Do we need to model transport constraints, such as: jitter, = disjoint, path diversity? Resolution #9: Propose a "transport-constraint" group with = "constraint-type", "constraint-value" and "constraint-list" (composed of = type and values) Status #9: Authors to propose the resolution in the I-D and provide to = the WG Discussion on #9: =20 =20 =20 Luis mentioned that they have multicast transport (multiple sites) and = bi-directional traffic applications (financial) that will require = transport constraints =20 Duplicate transport constraints for unicast and multicast to give = options for separate configuration. Keep single list entries for each src/dst pair even in the multicast = variant. =20 DO we need to support multiple constraints or just have a single = composite (of multiple constraints), have the ability to specify a = constraint-list? Aijun prfers list of constraints and meeting agrees this is OK =20 What constraints to offer? Latency Path diversty Site diversty Jitter Class of service was proposed but rejected =20 Luis highlighted they have a current implementation that uses the = similar proposal. Luis also mentioned that site diversity might also be = required, would this be achievable =20 =20 Issue#10: VPN "merging" Resolution #10: =20 Status #10: Discussion on #10: =20 =20 VPN is a per site property.=20 - A site can belong tomultiple VPNs - How to handle merging of two VPNs? - Is this an issue the service model has to deal with? =20 If VPN merging is required to be seamless, then this would be device = specific and not service model related. =20 =20 "Merging" is a confusing term. The objective is NOT to merge VPN1 and = VPN2. The objective is to provide an extranet so that some sites in VPN1 can = connect to some sites in VPN2 for some traffic. This can be solved using a per-site property. =20 Action: Need to update this issue to make it clear what function was = being discussed, also Stephane will send options to the working group- = list.=20 We are specifically looking for people who offer extranet connection = between sites from different VPNs =20 =3D=3D Other Issues =3D=3D =20 =20 Modeling Customer Specific Info - Create appropiate containers for Provider Edge and Customer Site = routers - The current model contains routing parametres that refer to CE and PE = relationships - General agreement is routing info should be split and current proposal = will be sent to the list for Kenichi, and working groups, review.=20 =20 =3D=3D Conclusions =3D=3D =20 - A number of resolutions have been agreed and will be updated in the = I-D - Chairs would like to see revised I-D based on the agreed points - Plan to have another interim call at the end of January (2016) - Chairs to add new tracker items, including security for future = discussion.=20 =20 _______________________________________________ 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 = 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, France Telecom - 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was 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, France Telecom - 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Sun Feb 21 18:19:07 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E591B1B316F for ; Sun, 21 Feb 2016 18:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 U-PBcJYD2tO9 for ; Sun, 21 Feb 2016 18:19:02 -0800 (PST) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id 389EA1B3157 for ; Sun, 21 Feb 2016 18:18:58 -0800 (PST) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id 1FD81E00FE; Mon, 22 Feb 2016 11:18:57 +0900 (JST) Received: from LTMC2145.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Mon, 22 Feb 2016 11:18:57 +0900 Received: from LTMC2145.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id E5BFD3A0065; Mon, 22 Feb 2016 11:18:56 +0900 (JST) Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2145.kddi.com (Postfix) with ESMTP id DAD003A005F; Mon, 22 Feb 2016 11:18:56 +0900 (JST) Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1M2Iuft006617; Mon, 22 Feb 2016 11:18:56 +0900 Received: from LTMC2152.kddi.com.mid_31961383 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1M28tOB027247; Mon, 22 Feb 2016 11:08:55 +0900 X-SA-MID: 31961383 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Mon, 22 Feb 2016 11:08:54 +0900 From: "Ogaki, Kenichi" To: , References: <11137_1452868271_569902AF_11137_18933_1_9E32478DFA9976438E7A22F69B08FF921683F2D0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <009a01d1518a$dccd16e0$966744a0$@kddi.com> <28946_1453107612_569CA99C_28946_1310_1_9E32478DFA9976438E7A22F69B08FF921683F60F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <000001d15266$38428380$a8c78a80$@kddi.com> In-Reply-To: <000001d15266$38428380$a8c78a80$@kddi.com> Date: Mon, 22 Feb 2016 11:08:54 +0900 Message-ID: <002c01d16d15$fb50c390$f1f24ab0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5Bq8eqk2F/jjoJjePPJmqqbPofQJPFi+8Aw+DAN8BzQ7zqZ6uwMOw Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Modeling a site with multiple subsites X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 22 Feb 2016 02:19:06 -0000 Hi Stephane and All, >>How to you differentiate multihoming from your subVPN case? they are = two different=20 >things. >As I wrote, we just have to *duplicate* vpn-policy under = site-network-access. When=20 >an operator's use case requires multiVPN, then vpn-policy should be = under sites as=20 >the current model does. >When the other operator requires subVPN, vpn-policy should just be = under site- >network-access. It's sufficient to use these two cases exclusively. Here is a minimum modification proposal to the current model in order to = use these two cases exclusively. Only if a vpn-policy is not defined directly under sites, we can define = it under site-network-access. If something is grammatically wrong in terms of YANG and XPATH = expression, could anyone correct me? ... container site-network-accesses { list site-network-access { uses site-vpn-policy { refine vpn-policy { when "not(../../../vpn-policy)"; } } ... } ... } =20 ... Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Tuesday, January 19, 2016 12:05 PM To: stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi Stephane, >We cannot use site-network-access which is used for multihoming only. Why do we have to use site-network-access only for multihoming? This is = intuitively mapped to a logical access as you wrote. >How to you differentiate multihoming from your subVPN case? they are = two different things. As I wrote, we just have to *duplicate* vpn-policy under = site-network-access. When an operator's use case requires multiVPN, then = vpn-policy should be under sites as the current model does. When the other operator requires subVPN, vpn-policy should just be under = site-network-access. It's sufficient to use these two cases exclusively. >Could you provide more technical detail so I will be able to understand = what exactly you are trying to achieve ? Our existing commercial service allows the *logically* following = diagram. PE1, PE2 and PE3 can be VRFs inside a single physical PE, or may be = physically separate PEs. Same as CEs. L2SW can be QinQ sub-interfaces on = a single physical PE depending on the above case. Then, we may map each element like this. sites: A customer premises connected via QinQ (stag 100) sub-sites: A customer premises' layer 2 segment separated by .1Q (ctag = 10 or 20), a ctag segment can include multiple logical accesses with bgp = peer per logical access. For example, PE1 has a bgp peer with CE1, and = PE2 has a different bgp peer with CE2. In this case, when VPN X only talks to LAN X, we need subVPN inside = sub-sites. But, we can deal with a sub-sites as a sites for the = simplicity to minimally extend the current model. Even so, we still need = vpn-policy per site-network-access. +-----------------------------+ +------------------------------+ | | | | | /---\ ctag 10 | | ctag 10 /---\ | | VPN A-+ PE1 +--------+ | | +--------+ CE1 +-LAN A | | \---/ | | | | \---/ | | | | | | | | /---\ctag 10+-+----+ |stag 100| +----+-+ctag 10/---\ | | VPN B-+ PE2 +------+ L2SW +-+--------+-+ L2SW +------+ CE2 +-LAN B | | \---/ +-+----+ | | +----+-+ \---/ | | | | | | | | /---\ctag 20 | | | | ctag 20 /---\ | | VPN C-+ PE3 +--------+ | | +--------+ CE3 +-LAN C | | \---/ | | \---/ | | | | | +-----------------------------+ +------------------------------+ Central Office Customer Premises All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Monday, January 18, 2016 6:00 PM To: Ogaki, Kenichi; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi, We cannot use site-network-access which is used for multihoming only. How to you differentiate multihoming from your subVPN case ? they are = two different things. So I'm completely against using site-network-accesses as a subVPN can be = also multihomed ... > FYI, our commercial service honestly has a similar element as = sub-sites, corresponding to vlan, but we still allows multiple vpns and = bgp peers, each different vpn access per peer, within a single vlan. Could you provide more technical detail so I will be able to understand = what exactly you are trying to achieve ? Best Regards, Stephane -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com]=20 Sent: Monday, January 18, 2016 01:55 To: LITKOWSKI Stephane SCE/OINIS; l3sm@ietf.org Subject: RE: [L3sm] Modeling a site with multiple subsites Hi Stephane, >Single "physical" access between SP and customer, but multiple = sub-accesses on top (VLAN, PPP sessions, or whatever ...), each one = pointing to a specific VPN. As you wrote above in the scenario a) and b), vpn-policy only have to be = controlled per logical access, equivalent to the site-network-access in = the current model. To solve the issue as simple as possible, it's = sufficient to duplicate vpn-policy under site-network-access. In these cases, a completely different conceptual element, sub-sites, is = not required. This must bring a complexity, and sometimes hard to be = understood, depending on operator's usecase.=20 Although we shouldn't discuss the device modelling, the granularity of = sub-sites corresponds to a VRF's one from the viewpoint of vpn-policy. = In this case, nobody intuitively imagines (sub-)sites from VRF, because = it's commonly in a single physical box. FYI, our commercial service honestly has a similar element as sub-sites, = corresponding to vlan, but we still allows multiple vpns and bgp peers, = each different vpn access per peer, within a single vlan. All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Friday, January 15, 2016 11:31 PM To: l3sm@ietf.org Subject: [L3sm] Modeling a site with multiple subsites [Creating another topic for better followup] =20 Today the model has the ability to create sites, a site can be = multihomed to the network thanks to the site-network-access sub-tree. =20 Now the question is how to we model such scenarios : =20 a) "SUBVPN case" : Single "physical" access between SP and = customer, but multiple sub-accesses on top (VLAN, PPP sessions, or = whatever .), each one pointing to a specific VPN. It is expected for the = customer to ensure flow separation (VRF lite, VLANs .). It's typically a = big company with a Hub site used where affiliates have dedicated = resources in the Hub site, and affiliates must not talk to each other or = even share resources. Note that I putted "physical" between quotes = because it can be a nested logical accesses . =20 =20 b) "INTER-AS option A like " case : this is the back to back VRF = case, as previously single "physical" access and multiple logical = accesses on top each one pointing to a separate VPN. I putted interAS, = but this can be "intra-AS" with iBGP back to back VRFs also (internal DC = for example) =20 c) What about option B ? Do we consider option B as a service ? I = would not be in favor of that. Option B setups are really particular in = term of design, security . So I would like to have option B out of = scope. =20 =20 Even if a) and b) are separated use cases from a service point of view, = these are similar in term of modeling. =20 Today we can model it has a collection of separated sites without any = relationship between each other. The other point is that we cannot = express any property of the "physical" attachment but there may few = (encryption ?). We can keep the model as it is with this limitation or = we can create site and sub-site hierarchy which as I already said may = complexify the reading and usability (IMO). It may look like this : =20 =B7 Sites o Site-only-parameters : =A7 Location =A7 Diversity =A7 management =A7 Security o Specific-parameters : <- to be used only if there is no subsite. =A7 Vpn-policy =A7 Services =A7 Routing-protocols =A7 Site-network-accesses =B7 .. o Sub-sites : <- to be used in case of sub sites present =A7 Specific-parameters : =B7 Vpn-policy =B7 Services =B7 Routing-protocols =B7 Site-network-accesses o . =20 I'm also wondering if bearer parameters must also be taken out in this = case and putted in the site-only-parameters.=20 The hierarchy becomes really complex here and I would like to keep it as = simple as possible. =20 =20 Would be good to have multiple feedbacks from the WG to see where the = consensus is. =20 =20 Orange logo =20 =20 Stephane Litkowski=20 Network Architect=20 Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 28 49 83 = =20 mobile: +33 6 37 86 97 52 = =20 stephane.litkowski@orange.com =20 =20 =20 _________________________________________________________________________= ________________________________________________ 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 _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Mon Feb 22 22:22:49 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1AE1B2C50 for ; Mon, 22 Feb 2016 22:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 Zpm8Fn-JKFXa for ; Mon, 22 Feb 2016 22:22:46 -0800 (PST) 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 F15631B2C47 for ; Mon, 22 Feb 2016 22:22:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEW55677; Tue, 23 Feb 2016 06:22:25 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 23 Feb 2016 06:22:24 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Tue, 23 Feb 2016 14:22:17 +0800 From: Qin Wu To: "Ogaki, Kenichi" , "l3sm@ietf.org" Thread-Topic: [L3sm] Notification support on L3SM Thread-Index: AdFHc4SIhFcUHomYSQSu07FkbZIQ5wmi+yMQ Date: Tue, 23 Feb 2016 06:22:16 +0000 Message-ID: References: <016a01d14777$ce9ef7e0$6bdce7a0$@kddi.com> In-Reply-To: <016a01d14777$ce9ef7e0$6bdce7a0$@kddi.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.208] 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.56CBFAB1.00C6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a457d8c36dd4f161c14726c5d7e4b187 Archived-At: Subject: Re: [L3sm] Notification support on L3SM X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2016 06:22:48 -0000 SGksIEtlbmljaGk6DQpOb3RpZmljYXRpb24gc3VwcG9ydCBpcyBub3QgYSBuZXcgZmVhdHVyZSBp biBZQU5HIDEuMSBhbmQgaXQgaGFzIGFscmVhZHkgYmVlbiBzdXBwb3J0ZWQgYnkgWUFORyAxLjAu DQpUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFlBTkcgMS4xIGFuZCBZQU5HIDEuMCBmb3IgTm90aWZp Y2F0aW9uIGlzIHRvIHJlbW92ZSB0aWUgd2l0aCBORVRDT05GLCBtYWtlIG5vdGlmaWNhdGlvbiBu b3Qgb25seSBhcHBsaWVkIHRvIE5FVENPTkYgYnV0IGFsc28gUkVTVENPTkYgb3Igb3RoZXIgdHJh bnNwb3J0IHByb3RvY29scy4NCg0KSW4gYWRkaXRpb24sIFlBTkcgMS4xIGNsZWFybHkgc3BlY2lm eSBsb2NhdGlvbiBvZiBub3RpZmljYXRpb24gaW4gdGhlIHNjaGVtYSB0cmVlLg0KU2VlIHBhcmFn cmFwaCAyLCBzZWN0aW9uIDcuMTYgb2YgcmZjNjAyMGJpcw0KIg0KTm90aWZpY2F0aW9uIHNob3Vs ZCBiZSBkZWZpbmVkIGF0IHRoZSB0b3AtbGV2ZWwgb2YgYSBtb2R1bGUsIG9yDQpjb25uZWN0ZWQg dG8gYSBzcGVjaWZpYyBjb250YWluZXIgb3IgbGlzdCBkYXRhIG5vZGUgaW4gdGhlIHNjaGVtYQ0K dHJlZS4gDQoiDQpJdCBjYW4gbm90IGJlIHJhbmRvbWx5IGRlZmluZWQgYXQgYW55IG90aGVyIHBs YWNlIGluIHRoZSBzY2hlbWEgdHJlZS4gDQpJIGFtIHdvbmRlcmluZyB3aGV0aGVyIHRoZXJlIGlz IGFueSBzcGVjaWZpYyBkYXRhIHlvdSB3YW50IHRvIGFkZCBpbiB0aGUgc2VydmljZSBtb2RlbCBi ZXNpZGVzICJhbnlkYXRhIGRhdGEiPw0KSWYgdGhlcmUgaXMgbm8gc3BlY2lmaWMgZGF0YSB0aGF0 IG5lZWRzIHRvIGJlIGFkZGVkLCBJIHRoaW5rIHdlIGtlZXAgc2VydmljZSBtb2RlbCBzaW1wbGUg YXMgYmFzZSBtb2RlbCwgZXh0ZW5kIGl0IGF0IGFueSB0aW1lIHRocm91Z2ggYXVnbWVudGF0aW9u IHdoZW4gc3BlY2lmaWMgZGF0YSBpcyBuZWVkZWQuDQoNCi1RaW4NCi0tLS0t08q8/tStvP4tLS0t LQ0Kt6K8/sjLOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIE9nYWtp LCBLZW5pY2hpDQq3osvNyrG85DogMjAxNsTqMdTCNcjVIDEzOjEzDQrK1bz+yMs6IGwzc21AaWV0 Zi5vcmcNCtb3zOI6IFtMM3NtXSBOb3RpZmljYXRpb24gc3VwcG9ydCBvbiBMM1NNDQoNCkRlYXIg QWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gYXNrIHlvdSBpZiBhIG5vdGlmaWNhdGlvbiBzdXBwb3J0 IGlzIG5lY2Vzc2FyeSBvbiB0aGUgbW9kZWwuDQpJIGRvbid0IHdhbnQgdG8gc3RpY2sgdG8gdGhp cyBhdCB0aGlzIHBoYXNlLCBidXQgdGhlcmUgYXJlIHNvbWUgdXNlIGNhc2VzLg0KDQpPcGVyYXRv cnMgbXVzdCBzb21ldGltZXMgbm90aWZ5IHZhcmlvdXMgaW5mb3JtYXRpb24gdG8gY3VzdG9tZXJz IHVuZGVyIGVhY2ggU0xBIHdpdGggdGhlbS4NCi1tYWludGVuYW5jZSBzY2hlZHVsZSAocGxhbm5l ZCwgaW4gb3BlcmF0aW9uKSAtcHJvYWN0aXZlIHJlcG9ydCB3aGVuIGEgZmFpbHVyZSBvY2N1cnJl ZCgsIGV2ZW4gaWYgdGhlIGN1c3RvbWVyIGlzIG5vdCBhd2FyZSkNCg0KWUFORzEuMSB3aWxsIGFs bG93IG5vdGlmaWNhdGlvbnMgdG8gYmUgdGllZCB0byBkYXRhIG5vZGVzLg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzYwMjBiaXMtMDkjc2VjdGlvbi03 LjE2DQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbDNzbS8zNWVPMUtY WVlCRWhRNVRYSTBpaldlNU5xajQNCi0tDQoqbm90aWZpY2F0aW9uDQpIb3cgYWJvdXQgZGVmaW5p bmcgbm90aWZpY2F0aW9uIG5vZGUgdW5kZXIgdnBuLXN2YyBhbmQgc2l0ZS1uZXR3b3JrLWFjY2Vz cz8NCldlIHNvbWV0aW1lcyBoYXZlIHRvIGFjdGl2ZWx5IGluZm9ybSBvdXIgY3VzdG9tZXJzIG9m IGEgZmFpbHVyZSBvciBzb21ldGhpbmcuDQpXaGF0IGtpbmQgb2YgdGhlIGluZm9ybWF0aW9uIGRl cGVuZHMgb24gZWFjaCBvcGVyYXRvciwgdGhlbiBhbnlkYXRhIG9yIGFueXhtbCBzdWl0cyB0aGlz Lg0KDQpbU0xJXSBOb3RpZmljYXRpb24gYXJlIG5vcm1hbGx5IG5vdCBwYXJ0IG9mIHRoZSB0cmVl LCB3ZSBjYW4gY3JlYXRlIHJwY3Mgb3Igbm90aWZpY2F0aW9ucyBpZiBuZWNlc3NhcnkgdG8gcmV0 cmlldmUgb3BlcmF0aW9uYWwgaW5mb3MuDQpDb3VsZCB5b3UgcmFpc2UgYSBzZXBhcmF0ZSB0aHJl YWQgdG8gZGlzY3VzcyB0aGUgbmVlZCBvZiBub3RpZmljYXRpb25zID8NCg0KDQpleC4pDQpjb250 YWluZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzc2VzIHsNCiAgICBsaXN0IHNpdGUtbmV0d29yay1hY2Nl c3Mgew0KICAgICAgICBrZXkgc2l0ZS1uZXR3b3JrLWFjY2Vzcy1pZDsNCiAgICAgICAgLi4uDQog ICAgICAgIG5vdGlmaWNhdGlvbiBpbmZvIHsNCiAgICAgICAgICAgIGFueWRhdGEgZGF0YTsNCiAg ICAgICAgfQ0KICAgICAgICAuLi4NCn0NCi0tDQoNCi0tDQpLZW5pY2hpIE9nYWtpDQpLRERJIENv cnAuIHwgSVAgTmV0d29yayBEZXB0Lg0KKzgxLSgwKTgwLTU5NDUtOTEzOCB8IHd3dy5rZGRpLmNv bQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Ckwzc20gbWFpbGluZyBsaXN0DQpMM3NtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2wzc20NCg== From nobody Mon Feb 22 22:33:49 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93571B2F99; Mon, 22 Feb 2016 22:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 gLl_s3Qk_7nl; Mon, 22 Feb 2016 22:33:46 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DFF1B2F96; Mon, 22 Feb 2016 22:33:46 -0800 (PST) Received: from localhost ([::1]:46375 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aY6XY-0002b4-KR; Mon, 22 Feb 2016 22:33:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "l3sm issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, bill.wu@huawei.com X-Trac-Project: l3sm Date: Tue, 23 Feb 2016 06:33:44 -0000 X-URL: https://tools.ietf.org/l3sm/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/l3sm/trac/ticket/14 Message-ID: <058.8abc1d7266dd917fde5493f7c695803a@tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, bill.wu@huawei.com, l3sm@ietf.org X-SA-Exim-Mail-From: trac+l3sm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org Resent-Message-Id: <20160223063346.D4DFF1B2F96@ietfa.amsl.com> Resent-Date: Mon, 22 Feb 2016 22:33:46 -0800 (PST) Resent-From: trac+l3sm@tools.ietf.org Archived-At: Cc: l3sm@ietf.org Subject: [L3sm] [l3sm] #14 (l3vpn-service-model): Notification support on L3SM X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:33:48 -0000 #14: Notification support on L3SM One issue raised by Kenichi is whether a notification support is necessary on the model. Kenichi gave the following use cases. Operators must sometimes notify various information to customers under each SLA with them. -maintenance schedule (planned, in operation) -proactive report when a failure occurred(, even if the customer is not aware) YANG1.1 will allow notifications to be tied to data nodes. https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#section-7.16 https://mailarchive.ietf.org/arch/msg/l3sm/35eO1KXYYBEhQ5TXI0ijWe5Nqj4 -- Kenichi has the following proposal: How about defining notification node under vpn-svc and site-network- access? We sometimes have to actively inform our customers of a failure or something. What kind of the information depends on each operator, then anydata or anyxml suits this. For example, container site-network-accesses { list site-network-access { key site-network-access-id; ... notification info { anydata data; } ... } -- Stephane believed that Notification are normally not part of the tree, rpcs or notifications can be created if necessary to retrieve operational infos. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-l3sm-l3vpn-service- bill.wu@huawei.com | model@ietf.org Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: l3vpn- | Version: 2.0 service-model | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: l3sm From nobody Mon Feb 22 22:36:16 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45511B2BDC; Mon, 22 Feb 2016 22:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 kOKRZIiDRU2d; Mon, 22 Feb 2016 22:36:10 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDFBD1B300F; Mon, 22 Feb 2016 22:36:10 -0800 (PST) Received: from localhost ([::1]:46542 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aY6Zu-0000MA-Kh; Mon, 22 Feb 2016 22:36:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "l3sm issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, bill.wu@huawei.com X-Trac-Project: l3sm Date: Tue, 23 Feb 2016 06:36:10 -0000 X-URL: https://tools.ietf.org/l3sm/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/l3sm/trac/ticket/10#comment:2 Message-ID: <084.64c67160e485bbbaebb464fc4f42074a@tools.ietf.org> References: <069.147022bcf5d21df546f9a59c10090069@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <069.147022bcf5d21df546f9a59c10090069@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, bill.wu@huawei.com, l3sm@ietf.org X-SA-Exim-Mail-From: trac+l3sm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org Resent-Message-Id: <20160223063610.CDFBD1B300F@ietfa.amsl.com> Resent-Date: Mon, 22 Feb 2016 22:36:10 -0800 (PST) Resent-From: trac+l3sm@tools.ietf.org Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] [l3sm] #10 (l3vpn-service-model): VPN policy : how to handle VPN merging easily X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:36:11 -0000 #10: VPN policy : how to handle VPN merging easily Changes (by bill.wu@huawei.com): * owner: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org => draft-ietf- l3sm-l3vpn-service-model@ietf.org * version: => 2.0 * component: draft-ltsd-l3sm-l3vpn-service-model => l3vpn-service-model * severity: - => Active WG Document * milestone: => milestone1 -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-l3sm-l3vpn- stephane.litkowski@orange.com | service-model@ietf.org Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: l3vpn-service-model | Version: 2.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: l3sm From nobody Mon Feb 22 22:37:26 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AB91A1A27; Mon, 22 Feb 2016 22:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 sQIYjADroFjq; Mon, 22 Feb 2016 22:37:23 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A5D1ABC75; Mon, 22 Feb 2016 22:37:21 -0800 (PST) Received: from localhost ([::1]:46604 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aY6b3-0002tp-8i; Mon, 22 Feb 2016 22:37:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "l3sm issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, bill.wu@huawei.com, sunseawq@huawei.com X-Trac-Project: l3sm Date: Tue, 23 Feb 2016 06:37:21 -0000 X-URL: https://tools.ietf.org/l3sm/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/l3sm/trac/ticket/6#comment:3 Message-ID: <073.0e61c9f0a47c738227da6bcbb5b13156@tools.ietf.org> References: <058.76d8daadf18d08e5693c03c7b912707b@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <058.76d8daadf18d08e5693c03c7b912707b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, bill.wu@huawei.com, sunseawq@huawei.com, l3sm@ietf.org X-SA-Exim-Mail-From: trac+l3sm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org Resent-Message-Id: <20160223063721.78A5D1ABC75@ietfa.amsl.com> Resent-Date: Mon, 22 Feb 2016 22:37:21 -0800 (PST) Resent-From: trac+l3sm@tools.ietf.org Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] [l3sm] #6 (l3vpn-service-model): Inventory ops state X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:37:24 -0000 #6: Inventory ops state Changes (by bill.wu@huawei.com): * owner: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org => draft-ietf- l3sm-l3vpn-service-model@ietf.org * version: => 2.0 * component: draft-ltsd-l3sm-l3vpn-service-model => l3vpn-service-model * severity: - => Active WG Document * milestone: => milestone1 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-l3sm-l3vpn-service- bill.wu@huawei.com | model@ietf.org Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: l3vpn- | Version: 2.0 service-model | Resolution: Severity: Active WG | Document | Keywords: oper state | -------------------------+------------------------------------------------- Ticket URL: l3sm From nobody Mon Feb 22 22:39:21 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E845D1B303B; Mon, 22 Feb 2016 22:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 VlgtD2RIV4jO; Mon, 22 Feb 2016 22:39:20 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147B91B300F; Mon, 22 Feb 2016 22:39:20 -0800 (PST) Received: from localhost ([::1]:46696 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aY6cs-0008D2-R4; Mon, 22 Feb 2016 22:39:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "l3sm issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, wangaj@ctbri.com.cn, bill.wu@huawei.com X-Trac-Project: l3sm Date: Tue, 23 Feb 2016 06:39:14 -0000 X-URL: https://tools.ietf.org/l3sm/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/l3sm/trac/ticket/1#comment:3 Message-ID: <074.5f7a3f589517205b562423321d04e385@tools.ietf.org> References: <059.79e873c38086a4cb2843a9d306fe4bca@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <059.79e873c38086a4cb2843a9d306fe4bca@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, wangaj@ctbri.com.cn, bill.wu@huawei.com, l3sm@ietf.org X-SA-Exim-Mail-From: trac+l3sm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org Resent-Message-Id: <20160223063920.147B91B300F@ietfa.amsl.com> Resent-Date: Mon, 22 Feb 2016 22:39:20 -0800 (PST) Resent-From: trac+l3sm@tools.ietf.org Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] [l3sm] #1 (l3vpn-service-model): When is customer-nat-address used? X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:39:21 -0000 #1: When is customer-nat-address used? Changes (by bill.wu@huawei.com): * owner: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org => draft-ietf- l3sm-l3vpn-service-model@ietf.org * version: => 2.0 * component: draft-ltsd-l3sm-l3vpn-service-model => l3vpn-service-model * severity: - => Active WG Document * milestone: => milestone1 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-l3sm-l3vpn-service- adrian@olddog.co.uk | model@ietf.org Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: l3vpn- | Version: 2.0 service-model | Resolution: Severity: Active WG | Document | Keywords: NAT | -------------------------+------------------------------------------------- Ticket URL: l3sm From nobody Mon Feb 22 22:39:49 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140D11B306C for ; Mon, 22 Feb 2016 22:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 7SL5Jnsit8kC for ; Mon, 22 Feb 2016 22:39:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4553B1B3048 for ; Mon, 22 Feb 2016 22:39:47 -0800 (PST) Received: from localhost ([::1]:46732 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aY6dP-0000mQ-15; Mon, 22 Feb 2016 22:39:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "l3sm issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: bill.wu@huawei.com X-Trac-Project: l3sm Date: Tue, 23 Feb 2016 06:39:46 -0000 X-URL: https://tools.ietf.org/l3sm/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/l3sm/trac/ticket/3#comment:1 Message-ID: <073.d05ab02e912b2819e8f028061216a6ae@tools.ietf.org> References: <058.69a0419896cb64150b52a88793b4a255@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <058.69a0419896cb64150b52a88793b4a255@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bill.wu@huawei.com, l3sm@ietf.org X-SA-Exim-Mail-From: trac+l3sm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] [l3sm] #3 (l3vpn-service-model): M to N availability support X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:39:48 -0000 #3: M to N availability support Changes (by bill.wu@huawei.com): * version: => 2.0 * component: draft-ltsd-l3sm-l3vpn-service-model => l3vpn-service-model * severity: - => Active WG Document * milestone: => milestone1 -- ---------------------------------+-------------------------------- Reporter: bill.wu@huawei.com | Owner: Site Availability Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: l3vpn-service-model | Version: 2.0 Severity: Active WG Document | Resolution: Keywords: | ---------------------------------+-------------------------------- Ticket URL: l3sm From nobody Mon Feb 22 22:40:25 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DAC1B30AD; Mon, 22 Feb 2016 22:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 4CXMepqWn2VW; Mon, 22 Feb 2016 22:40:23 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50BA01B309F; Mon, 22 Feb 2016 22:40:23 -0800 (PST) Received: from localhost ([::1]:46799 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aY6dz-00020F-4C; Mon, 22 Feb 2016 22:40:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "l3sm issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, bill.wu@huawei.com X-Trac-Project: l3sm Date: Tue, 23 Feb 2016 06:40:23 -0000 X-URL: https://tools.ietf.org/l3sm/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/l3sm/trac/ticket/5#comment:2 Message-ID: <073.a73ab3b892cf47ff7d339334aa8d1fa8@tools.ietf.org> References: <058.5c4321db51ad8ec753f5ee16f27d8519@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <058.5c4321db51ad8ec753f5ee16f27d8519@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, bill.wu@huawei.com, l3sm@ietf.org X-SA-Exim-Mail-From: trac+l3sm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org Resent-Message-Id: <20160223064023.50BA01B309F@ietfa.amsl.com> Resent-Date: Mon, 22 Feb 2016 22:40:23 -0800 (PST) Resent-From: trac+l3sm@tools.ietf.org Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] [l3sm] #5 (l3vpn-service-model): Multicast Support for L3VPN service X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:40:24 -0000 #5: Multicast Support for L3VPN service Changes (by bill.wu@huawei.com): * owner: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org => draft-ietf- l3sm-l3vpn-service-model@ietf.org * version: => 2.0 * component: draft-ltsd-l3sm-l3vpn-service-model => l3vpn-service-model * severity: - => Active WG Document * milestone: => milestone1 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-l3sm-l3vpn-service- bill.wu@huawei.com | model@ietf.org Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: l3vpn- | Version: 2.0 service-model | Resolution: Severity: Active WG | Document | Keywords: Multicast | -------------------------+------------------------------------------------- Ticket URL: l3sm From nobody Mon Feb 22 22:40:41 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4521B30B8; Mon, 22 Feb 2016 22:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 AnC3epR-JA3C; Mon, 22 Feb 2016 22:40:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50AD1B309F; Mon, 22 Feb 2016 22:40:39 -0800 (PST) Received: from localhost ([::1]:46830 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aY6eF-00028V-Ld; Mon, 22 Feb 2016 22:40:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "l3sm issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, bill.wu@huawei.com X-Trac-Project: l3sm Date: Tue, 23 Feb 2016 06:40:39 -0000 X-URL: https://tools.ietf.org/l3sm/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/l3sm/trac/ticket/7#comment:2 Message-ID: <073.c7a1af44d2b71999b1d562e8e3f0f2b0@tools.ietf.org> References: <058.1158c5281ecc019e153f7c608ae42584@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <058.1158c5281ecc019e153f7c608ae42584@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, bill.wu@huawei.com, l3sm@ietf.org X-SA-Exim-Mail-From: trac+l3sm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org Resent-Message-Id: <20160223064039.D50AD1B309F@ietfa.amsl.com> Resent-Date: Mon, 22 Feb 2016 22:40:39 -0800 (PST) Resent-From: trac+l3sm@tools.ietf.org Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] [l3sm] #7 (l3vpn-service-model): Generic VAS X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:40:40 -0000 #7: Generic VAS Changes (by bill.wu@huawei.com): * owner: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org => draft-ietf- l3sm-l3vpn-service-model@ietf.org * version: => 2.0 * component: draft-ltsd-l3sm-l3vpn-service-model => l3vpn-service-model * severity: - => Active WG Document * milestone: => milestone1 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-l3sm-l3vpn-service- bill.wu@huawei.com | model@ietf.org Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: l3vpn- | Version: 2.0 service-model | Resolution: Severity: Active WG | Document | Keywords: VAS | -------------------------+------------------------------------------------- Ticket URL: l3sm From nobody Mon Feb 22 22:41:02 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5B61A1A93; Mon, 22 Feb 2016 22:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 W1-8Wnqu4_qa; Mon, 22 Feb 2016 22:41:00 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE78C1A1A80; Mon, 22 Feb 2016 22:40:59 -0800 (PST) Received: from localhost ([::1]:46852 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aY6eW-0002Ga-E6; Mon, 22 Feb 2016 22:40:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "l3sm issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, michael.scharf@alcatel-lucent.com, sunseawq@huawei.com, bill.wu@huawei.com X-Trac-Project: l3sm Date: Tue, 23 Feb 2016 06:40:56 -0000 X-URL: https://tools.ietf.org/l3sm/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/l3sm/trac/ticket/9#comment:3 Message-ID: <084.e9bbb203de419de1c2a5eeb7661b0519@tools.ietf.org> References: <069.f8d1049aea3b55e0d76289f1989bc06f@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <069.f8d1049aea3b55e0d76289f1989bc06f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, michael.scharf@alcatel-lucent.com, sunseawq@huawei.com, bill.wu@huawei.com, l3sm@ietf.org X-SA-Exim-Mail-From: trac+l3sm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org Resent-Message-Id: <20160223064059.EE78C1A1A80@ietfa.amsl.com> Resent-Date: Mon, 22 Feb 2016 22:40:59 -0800 (PST) Resent-From: trac+l3sm@tools.ietf.org Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] [l3sm] #9 (l3vpn-service-model): Do we need to model transport constraints between sites ? X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:41:01 -0000 #9: Do we need to model transport constraints between sites ? Changes (by bill.wu@huawei.com): * owner: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org => draft-ietf- l3sm-l3vpn-service-model@ietf.org * version: => 2.0 * component: draft-ltsd-l3sm-l3vpn-service-model => l3vpn-service-model * severity: - => Active WG Document * milestone: => milestone1 -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-l3sm-l3vpn- stephane.litkowski@orange.com | service-model@ietf.org Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: l3vpn-service-model | Version: 2.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: l3sm From nobody Mon Feb 22 22:41:39 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8090F1A1C00; Mon, 22 Feb 2016 22:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 9MZVKqrX4YX3; Mon, 22 Feb 2016 22:41:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EF81A1A83; Mon, 22 Feb 2016 22:41:36 -0800 (PST) Received: from localhost ([::1]:46925 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aY6f7-0002Ya-Pv; Mon, 22 Feb 2016 22:41:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "l3sm issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, stephane.litkowski@orange.com, bill.wu@huawei.com X-Trac-Project: l3sm Date: Tue, 23 Feb 2016 06:41:33 -0000 X-URL: https://tools.ietf.org/l3sm/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/l3sm/trac/ticket/11#comment:2 Message-ID: <088.d64910f3193483861299bf41b37aebc3@tools.ietf.org> References: <073.8b06d60f615a9b8c47c7e7703a8ac183@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <073.8b06d60f615a9b8c47c7e7703a8ac183@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, stephane.litkowski@orange.com, bill.wu@huawei.com, l3sm@ietf.org X-SA-Exim-Mail-From: trac+l3sm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org Resent-Message-Id: <20160223064136.85EF81A1A83@ietfa.amsl.com> Resent-Date: Mon, 22 Feb 2016 22:41:36 -0800 (PST) Resent-From: trac+l3sm@tools.ietf.org Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] [l3sm] #11 (l3vpn-service-model): MUST for site diversity? X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:41:37 -0000 #11: MUST for site diversity? Changes (by bill.wu@huawei.com): * owner: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org => draft-ietf- l3sm-l3vpn-service-model@ietf.org * version: => 2.0 * component: draft-ltsd-l3sm-l3vpn-service-model => l3vpn-service-model * severity: - => Active WG Document * milestone: => milestone1 -- -------------------------------------+------------------------------------- Reporter: michael.scharf@alcatel- | Owner: draft-ietf-l3sm-l3vpn- lucent.com | service-model@ietf.org Type: defect | Status: new Priority: trivial | Milestone: milestone1 Component: l3vpn-service-model | Version: 2.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: l3sm From nobody Mon Feb 22 22:41:56 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52131A1C00; Mon, 22 Feb 2016 22:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 IXKhsAw8KY6P; Mon, 22 Feb 2016 22:41:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22771A1A33; Mon, 22 Feb 2016 22:41:53 -0800 (PST) Received: from localhost ([::1]:46947 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aY6fO-0002db-UD; Mon, 22 Feb 2016 22:41:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "l3sm issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, wangaj@ctbri.com.cn, bill.wu@huawei.com X-Trac-Project: l3sm Date: Tue, 23 Feb 2016 06:41:50 -0000 X-URL: https://tools.ietf.org/l3sm/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/l3sm/trac/ticket/4#comment:2 Message-ID: <073.34681660746830e615b0e660a8334dd4@tools.ietf.org> References: <058.56e473469b03509c9c244ea1a96c2616@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <058.56e473469b03509c9c244ea1a96c2616@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, wangaj@ctbri.com.cn, bill.wu@huawei.com, l3sm@ietf.org X-SA-Exim-Mail-From: trac+l3sm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org Resent-Message-Id: <20160223064153.F22771A1A33@ietfa.amsl.com> Resent-Date: Mon, 22 Feb 2016 22:41:53 -0800 (PST) Resent-From: trac+l3sm@tools.ietf.org Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] [l3sm] #4 (l3vpn-service-model): site-service-cloudaccess as grouping? X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:41:54 -0000 #4: site-service-cloudaccess as grouping? Changes (by bill.wu@huawei.com): * owner: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org => draft-ietf- l3sm-l3vpn-service-model@ietf.org * version: => 2.0 * component: draft-ltsd-l3sm-l3vpn-service-model => l3vpn-service-model * severity: - => Active WG Document * milestone: => milestone1 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-l3sm-l3vpn-service- bill.wu@huawei.com | model@ietf.org Type: enhancement | Status: new Priority: trivial | Milestone: milestone1 Component: l3vpn- | Version: 2.0 service-model | Resolution: Severity: Active WG | Document | Keywords: Cloudaccess | -------------------------+------------------------------------------------- Ticket URL: l3sm From nobody Mon Feb 22 22:42:12 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB441A1A33; Mon, 22 Feb 2016 22:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 GFOraANWrTOf; Mon, 22 Feb 2016 22:42:09 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5651A1A83; Mon, 22 Feb 2016 22:42:09 -0800 (PST) Received: from localhost ([::1]:46965 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aY6ff-0002j1-I1; Mon, 22 Feb 2016 22:42:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "l3sm issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, michael.scharf@alcatel-lucent.com, bill.wu@huawei.com, stephane.litkowski@orange.com, sunseawq@huawei.com X-Trac-Project: l3sm Date: Tue, 23 Feb 2016 06:42:07 -0000 X-URL: https://tools.ietf.org/l3sm/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/l3sm/trac/ticket/8#comment:8 Message-ID: <073.fa1915c3fe613b8ce0b832526f789144@tools.ietf.org> References: <058.982302c79a3ade70485a55c295f7857d@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <058.982302c79a3ade70485a55c295f7857d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org, michael.scharf@alcatel-lucent.com, bill.wu@huawei.com, stephane.litkowski@orange.com, sunseawq@huawei.com, l3sm@ietf.org X-SA-Exim-Mail-From: trac+l3sm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-l3sm-l3vpn-service-model@ietf.org Resent-Message-Id: <20160223064209.AD5651A1A83@ietfa.amsl.com> Resent-Date: Mon, 22 Feb 2016 22:42:09 -0800 (PST) Resent-From: trac+l3sm@tools.ietf.org Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] [l3sm] #8 (l3vpn-service-model): Who keep Site location information? X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:42:11 -0000 #8: Who keep Site location information? Changes (by bill.wu@huawei.com): * owner: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org => draft-ietf- l3sm-l3vpn-service-model@ietf.org * version: => 2.0 * component: draft-ltsd-l3sm-l3vpn-service-model => l3vpn-service-model * severity: - => Active WG Document * milestone: => milestone1 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-l3sm-l3vpn-service- bill.wu@huawei.com | model@ietf.org Type: enhancement | Status: new Priority: trivial | Milestone: milestone1 Component: l3vpn- | Version: 2.0 service-model | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: l3sm From nobody Tue Feb 23 16:19:26 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4001B3BF2 for ; Tue, 23 Feb 2016 16:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 4ROq9WpE2aqi for ; Tue, 23 Feb 2016 16:19:23 -0800 (PST) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id 0414B1B3BCF for ; Tue, 23 Feb 2016 16:19:23 -0800 (PST) Received: from LTMC2121.kddi.com (LTMC2121.kddi.com [10.206.0.61]) by post-send.kddi.com (KDDI Mail) with ESMTP id 159A0E0065; Wed, 24 Feb 2016 09:19:22 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2121.kddi.com with ESMTP; Wed, 24 Feb 2016 09:19:22 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id DAF594C005A; Wed, 24 Feb 2016 09:19:21 +0900 (JST) Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id CFF124C0058; Wed, 24 Feb 2016 09:19:21 +0900 (JST) Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1O0JLBs018613; Wed, 24 Feb 2016 09:19:21 +0900 Received: from LTMC2152.kddi.com.mid_32126045 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1O09HDx008282; Wed, 24 Feb 2016 09:09:17 +0900 X-SA-MID: 32126045 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Wed, 24 Feb 2016 09:09:17 +0900 From: "Ogaki, Kenichi" To: "'Qin Wu'" , References: <016a01d14777$ce9ef7e0$6bdce7a0$@kddi.com> In-Reply-To: Date: Wed, 24 Feb 2016 09:09:14 +0900 Message-ID: <004001d16e97$99f03b70$cdd0b250$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFLBNcSVsQUn+khBavUdKiLfmTsYgHkXmnqoDcaTxA= Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Notification support on L3SM X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 00:19:26 -0000 Hi Qin, >In addition, YANG 1.1 clearly specify location of notification in the = schema tree. >See paragraph 2, section 7.16 of rfc6020bis " >Notification should be defined at the top-level of a module, or = connected to a specific container or list data node in the schema tree.=20 >" >It can not be randomly defined at any other place in the schema tree.=20 In my understanding, the limitation of notification statement placed = only at top-level in YANG 1.0 is relieved to container and list in YANG = 1.1. An example is shown in just before section 7.17 of rfc6020bis. >I am wondering whether there is any specific data you want to add in = the service model besides "anydata data"? This intends that how to use the notification depends on each operator. >If there is no specific data that needs to be added, I think we keep = service model simple as base model, extend it at any time through = augmentation=20 >when specific data is needed. So, I don't stick to define the notification at this phase, unless a = strong requirement. Augmentation is good enough. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu Sent: Tuesday, February 23, 2016 3:22 PM To: Ogaki, Kenichi; l3sm@ietf.org Subject: Re: [L3sm] Notification support on L3SM Hi, Kenichi: Notification support is not a new feature in YANG 1.1 and it has already = been supported by YANG 1.0. The difference between YANG 1.1 and YANG 1.0 for Notification is to = remove tie with NETCONF, make notification not only applied to NETCONF = but also RESTCONF or other transport protocols. In addition, YANG 1.1 clearly specify location of notification in the = schema tree. See paragraph 2, section 7.16 of rfc6020bis " Notification should be defined at the top-level of a module, or = connected to a specific container or list data node in the schema tree.=20 " It can not be randomly defined at any other place in the schema tree.=20 I am wondering whether there is any specific data you want to add in the = service model besides "anydata data"? If there is no specific data that needs to be added, I think we keep = service model simple as base model, extend it at any time through = augmentation when specific data is needed. -Qin -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: L3sm [mailto:l3sm-bounces@ietf.org] =B4=FA=B1=ED = Ogaki, Kenichi =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA1=D4=C25=C8=D5 13:13 =CA=D5=BC=FE=C8=CB: l3sm@ietf.org =D6=F7=CC=E2: [L3sm] Notification support on L3SM Dear All, I would like to ask you if a notification support is necessary on the = model. I don't want to stick to this at this phase, but there are some use = cases. Operators must sometimes notify various information to customers under = each SLA with them. -maintenance schedule (planned, in operation) -proactive report when a = failure occurred(, even if the customer is not aware) YANG1.1 will allow notifications to be tied to data nodes. https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#section-7.16 https://mailarchive.ietf.org/arch/msg/l3sm/35eO1KXYYBEhQ5TXI0ijWe5Nqj4 -- *notification How about defining notification node under vpn-svc and = site-network-access? We sometimes have to actively inform our customers of a failure or = something. What kind of the information depends on each operator, then anydata or = anyxml suits this. [SLI] Notification are normally not part of the tree, we can create rpcs = or notifications if necessary to retrieve operational infos. Could you raise a separate thread to discuss the need of notifications ? ex.) container site-network-accesses { list site-network-access { key site-network-access-id; ... notification info { anydata data; } ... } -- -- Kenichi Ogaki KDDI Corp. | IP Network Dept. +81-(0)80-5945-9138 | www.kddi.com _______________________________________________ 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 From nobody Tue Feb 23 16:21:25 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0561B3055 for ; Tue, 23 Feb 2016 16:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.247 X-Spam-Level: ** X-Spam-Status: No, score=2.247 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=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 Nvby3Du7091K for ; Tue, 23 Feb 2016 16:21:21 -0800 (PST) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id DB7F31B2E07 for ; Tue, 23 Feb 2016 16:21:20 -0800 (PST) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id 814B3E0064; Wed, 24 Feb 2016 09:21:20 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Wed, 24 Feb 2016 09:21:20 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 5A8D94C005A; Wed, 24 Feb 2016 09:21:20 +0900 (JST) Received: from LTMC2151.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id 457274C0058; Wed, 24 Feb 2016 09:21:20 +0900 (JST) Received: from LTMC2151.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u1O0LJ7r031289; Wed, 24 Feb 2016 09:21:20 +0900 Received: from LTMC2151.kddi.com.mid_32557011 (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u1O0BFva019713; Wed, 24 Feb 2016 09:11:15 +0900 X-SA-MID: 32557011 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Wed, 24 Feb 2016 09:11:15 +0900 From: "Ogaki, Kenichi" To: "'Aijun Wang'" <13301168517@189.cn>, , References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> In-Reply-To: <004901d16a02$821e7cd0$865b7670$@cn> Date: Wed, 24 Feb 2016 09:11:15 +0900 Message-ID: <004101d16e97$e0692800$a13b7800$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+JsdlYZ7cvi/Fz8JTONaqj4LvoQKs2aO/ncrnHgA= Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 00:21:25 -0000 Hi Aijun, See comments inline, please. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 18, 2016 1:12 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Stephane and Ogaki: =20 I suggested we put the "extranet-vpn-policy" under the list "vpn-svc" = directly, not in the container "vpn-policy" that is now under the list = "sites" in current model.=20 [KO]Like this? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } ... } ... } This can solve the initial scenario that proposed by Kenichi at the = beginning of our discussion. When the orchestrator receives the = information defined in "extranet-vpn-policy", it can allocate new = route-target for the involved VPNs and set them in the configuration = stanza of each router. =20 For the relationship of list "vpn-svc" and list "sites", I still suggest = we put the list "site" under the "vpn-svc", the reason for doing this is = as below: 1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. [KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. In that sense, I basically prefer the current model. 2. The attributes of "sites", such as "maximum-routes", "security", = "service", "routing-protocols","site-netwok-accesses" etc. are all = service/site role related, that is to say, if the site role changed, all = of these attributed may be changed accordingly. [KO] I basically agree. The attributes tied to a whole vpn and globally = applied to all the sites under the vpn should be defined with the vpn = definition. 3.For container "vpn policy" that under list "sites" in current model, = there are two information defined, one is "filter" for prefix filtering, = another is "site-role". I suggest we split it, put the leaf "site-role" = under leaf "site-id" directly, and change the name of "vpn-policy" to = "site-prefix-policy".=20 =20 The final suggest structure of the L3VPN yang model will be look like = the bellow, I underline the changed positions from the current l3vpn = Yang Model =20 Container L3vpn-svc List vpn-svc Leaf vpn-id Leaf customer-name Leaf topology List extranet-vpn-policy Container cloud-access List multicast Leaf mpls List transport-contraints =20 List sites Leaf site-id Leaf site-role leaf apply-template ... ... ... ... Container managent Container site-prefix-policy Container maximum-routes Container security ... ... ... ... Site-network-access=20 =20 =20 Whether is it more reasonable?=20 =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute=20 Network Research and Operation Support Department =20 =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 18, 2016 9:08 AM To: l3sm@ietf.org Subject: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday = L3SM interim session =20 Hi Stephane and All, =20 As for issue #10 itself, the following solution can be acceptable for = us. =20 >One proposal could be to not call this VPN policy, but creating a=20 >container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). =20 What model is in your mind? I can't see what ""extranet-vpn-policy" at = vpn" means. Like this? =20 ... 1 VPN1 VPN2 ... =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of stephane.litkowski@orange.com = =20 Sent: Monday, December 07, 2015 11:45 PM To: Ogaki, Kenichi; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi Kenichi, =20 Regarding your proposal of having a simple VPN policy in the vpn-svc = container, I do see an issue. One of the key point of the VPN policy is = to express the role of the site in the target VPN topology. If we do a vpn policy at VPN level, we cannot anymore describe site = roles in the target VPN which causes an issue. In an ideal world where all VPNs are any to any, the site role is always = the same and there is no issue, but let's think about someone trying to = use the vpn-policy (at vpn level) to connect to a Hub & Spoke VPN, how = do you deduce the roles of the sites ? =20 One proposal could be to not call this VPN policy, but creating a = container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). This means that the usage is really limited to "simple" = extranet-vpns and it does not replace nor compete with the VPN policy at = site level. =20 Could it be a good compromise ? =20 Stephane =20 =20 -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com = ] Sent: Saturday, December 05, 2015 06:23 To: LITKOWSKI Stephane SCE/OINIS; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear Stephane and All, =20 I don't say that sites *must* move under vpn-svc because I understand = stephane's use case. But we already have vpn-svc and some parameters under this are globally = applied to all the sites even in the current model. =20 It depends on operator's use case which is site-oriented or vpn-oriented = service. Our service is vpn-oriented, site has the native VPN. Then, I would just = like you to allow other global options to vpn-svc. =20 Thanks, Kenichi =20 -----Original Message----- From: stephane.litkowski@orange.com = = [mailto:stephane.litkowski@orange.com = ] Sent: Friday, December 04, 2015 8:17 PM To: Aijun Wang; 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi, =20 I'm against this proposal, as I do not want to create any dependency = between a particular VPN and a list of sites. A site can belong to multiple VPNs with any kind of topology, if we = attach the site to a single VPN, we come back to the notion of "native = VPN" we had at the beginning of the model which was hard to understand = and so was removed. =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Aijun Wang Sent: Friday, December 04, 2015 02:44 To: 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear all: =20 Can we put the list "sites" within the list "vpn-svc", and define the = general vpn policy for all sites that within the corresponding vpn = service instance? If doing so, some entries within the current list "sites" can also be = dragged out for general usual purposes, for example, "maximum-routes", = "security" etc. These parameters are often all same for every site = within one VPN service instance.=20 =20 If some sites have special requirements, we can achieve this by using = some special "site-vpn-policy" within the corresponding site definition. Is this more acceptable for customers? =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute Intelligent = Network Product Line =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Ogaki, Kenichi Sent: Friday, December 04, 2015 9:02 AM To: 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear All, =20 It was good having discussion. =20 As for issue#10, the objective and problem we discussed in the meeting = as follows. =20 The objective is to provide per-VPN extranet service which connects two = different VPNs (e.g. VPN1 and VPN2). It means that any sites in VPN1 can = access to any sites in VPN2. The problem is that the current model must update vpn-policy under all = the sites belong to these two VPNs in order to offer this service. = Especially when this model is used as a customer self-control API, it's = not good idea to require customers to update the information of all the = sites. (It's not abstracted way, a service model should provide what the = consumer wants, not how.) If a service or customer requires to control = per-site vpn-policy, that of current model should be used without = setting per-VPN vpn-polity. It depends on each operator's service. Stephane proposed to use apply-template, but it still cannot solve the = problem. When each VPN already has a large number of sites and want to = connect each other for the first time, both VPNs must update these sites = to apply apply-template on the current model. =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Qin Wu Sent: Friday, December 04, 2015 12:42 AM To: l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: [L3sm] L3SM interim meeting minutes on Thursday L3SM interim = session =20 Hi all: =20 =20 Below is the initial version of draft minutes for Thursday L3SM WG = interim session. =20 Thanks Dan to help take minutes. =20 Folks, please let us know if you have any correction. =20 =20 -Qin =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =20 L3SM Working Group Virtual Interim Meeting=20 =20 Thursday December 5th, 2015. 8am East Coast Time (New York) =20 =20 BLUE SHEET =20 =20 Name | Affiliation =20 ------------------------+----------------------------------------------- ------------------------+- =20 Adrian Farrel | Old Dog Consulting =20 Qin Wu | Huawei Technologies =20 Stephane Litkowski | Orange =20 Luis Tomotaki | Verizon =20 Daniel King | Old Dog Consulting =20 Susan Hares | Huawei Technologies =20 Scott Mansfield | Ericsson =20 Gu Rong | China Mobile=20 =20 Kenichi Ogaki | KDDI =20 Aijun Wang | China Telecom =20 Victor Santos | Ericsson =20 Ignas Bagdonas |=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 MINUTES =20 =20 * Meting logiistics = https://mailarchive.ietf.org/arch/msg/l3sm/SJub1aHVQGOQW6rWhthX0fB8Ac8 = = =20 =20 * Meeting materials = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/proceedings.html= = =20 =20 * Etherpad for minutes (this page) = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03 = =20 =20 * Jabber using l3sm@jabber.ietf.org =20 =20 * Blue sheet = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03-bluesheet = = =20 =20 =20 Agendaa =20 - Administrivia (Note Well, etc). a =20 - Introduction =20 - Open Issues for YANG Data Model for L3VPNservice delivery = (draft-ietf-l3sm-l3vpn-servicemodel) =20 o Open Issues discussion and resolution=E2=80=93 = http://trac.tools.ietf.org/wg/l3sm/trac/report/1 = =20 =20 =20 For a full list of issues and resolution proposals please see: = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/slides/slides-in= terim-2015-l3sm-1-2.pdf = =20 =20 =20 Issue#1: When customer-nat-address is used =20 Resolution #1: Leaf used when NAT is required to access cloud VPN and = customer wants to use its ownIP address. If provider provides the public = IP,no need to use the leaf =20 Status #1: Closed Pending I-D text review. =20 =20 Discussion on #1:=20 =20 =20 Aijun asks for more description in the YANG model itself =20 Stephane shows current model =20 Agreed OK =20 =20 Issue#2 : Identify l3vpn svc using id or name or both =20 Resolution #2: ID is a string, as per other properties in the model =20 Status #2: Closed =20 Discussion on #2:=20 =20 =20 Agreed OK =20 =20 Issue#3: M to N availability support =20 Resolution #3: Modeling sites using a list with a priority, so include = access list with a priority. =20 Status #3: =20 Discussion on #3:=20 =20 =20 Qin was asking that M to N availability is supported with access and = priority number.=20 =20 Stephane stated this is suppoted. This new proposal also supports = multiple sites, as a list. =20 Qin also asked if Group I-D was no longer needed, which it is not. Also = good solution supported by other operators. =20 Stephane asked if four priorities was enough, or if more were needed.=20 =20 =20 Re: Containers/Properties for Network Access Configuration - = Conclusions? =20 =20 o Location - Different site I-D? =20 o QoS Policy - Per network access link, or site information? Would QoS = (cost) be different per accesslink or site? Example of Primary and = Backup links given.=20 =20 o Bandwidth - Moved to access link group=20 =20 o Maximum Routes -=20 =20 Security, routing, and services are duplicated with inheritance =20 =20 =20 Issue#4: site-service-cloud access as grouping =20 Resolution #4 Already resilved as a separate grouping =20 Status #4: Closed =20 Discussion on #4:=20 =20 =20 Issue#5: Multicast support as raised by Eric Rosen =20 Resolution #5: : New "provider managed" property, and in Site Properties = "property-type" added =20 Status #5: Solution proposed.=20 =20 Discussion on #5:=20 =20 =20 Stephane will proviode new property proposals will be provided to Eric = for review.=20 =20 =20 Issue#6: Inventory operational state =20 Resolution #6: Include a new container for inventory state, or an RPC = call (sitting above the service orchestrator) to retrieve inventory = state.=20 =20 Status #6: Need to propose to the WG and agree solution. =20 Discussion on #6:=20 =20 =20 Luis asked would this info be collected from provision state? Stephane = suggested this would not be availible.=20 =20 Adrian observed that the code used to convert the model into a service = request may not utilise this inventory information capability. Sue = mentioned that others have mentioned by a vendor that it would be useful = to have the ability to configure inventory state. This should be = clarified by the operators.=20 =20 =20 Stephane to take proposals to list and ask anyone who is interested in = having the feature to suggest text. =20 =20 =20 Issue#7: Generic VAS - do we need to create a generic VAS container as = VAS are popular in L3VPNs? =20 Resolution #7: Separate from L3SM =20 Status #7: Closed =20 Discussion on #7:=20 =20 =20 Gu Rong highlighted Generic VAS model which was presented at IETF 94.=20 =20 =20 Issue#8: Who keeps site locationinformation? =20 Resolution #8: Text has been fixed =20 Status #8: Closed =20 Discussion on #8:=20 =20 =20 =20 Issue#9: Do we need to model transport constraints, such as: jitter, = disjoint, path diversity? =20 Resolution #9: Propose a "transport-constraint" group with = "constraint-type", "constraint-value" and "constraint-list" (composed of = type and values) =20 Status #9: Authors to propose the resolution in the I-D and provide to = the WG =20 Discussion on #9: =20 =20 =20 =20 Luis mentioned that they have multicast transport (multiple sites) and = bi-directional traffic applications (financial) that will require = transport constraints =20 =20 Duplicate transport constraints for unicast and multicast to give = options for separate configuration. =20 Keep single list entries for each src/dst pair even in the multicast = variant. =20 =20 DO we need to support multiple constraints or just have a single = composite (of multiple constraints), have the ability to specify a = constraint-list? =20 Aijun prfers list of constraints and meeting agrees this is OK =20 =20 What constraints to offer? =20 Latency =20 Path diversty =20 Site diversty =20 Jitter =20 Class of service was proposed but rejected =20 =20 Luis highlighted they have a current implementation that uses the = similar proposal. Luis also mentioned that site diversity might also be = required, would this be achievable =20 =20 =20 Issue#10: VPN "merging" =20 Resolution #10: =20 =20 Status #10: =20 Discussion on #10: =20 =20 =20 VPN is a per site property.=20 =20 - A site can belong tomultiple VPNs =20 - How to handle merging of two VPNs? =20 - Is this an issue the service model has to deal with? =20 =20 If VPN merging is required to be seamless, then this would be device = specific and not service model related. =20 =20 =20 "Merging" is a confusing term. The objective is NOT to merge VPN1 and = VPN2. =20 The objective is to provide an extranet so that some sites in VPN1 can = connect to some sites in VPN2 for some traffic. =20 This can be solved using a per-site property. =20 =20 Action: Need to update this issue to make it clear what function was = being discussed, also Stephane will send options to the working group- = list.=20 =20 We are specifically looking for people who offer extranet connection = between sites from different VPNs =20 =20 =3D=3D Other Issues =3D=3D =20 =20 =20 Modeling Customer Specific Info =20 - Create appropiate containers for Provider Edge and Customer Site = routers =20 - The current model contains routing parametres that refer to CE and PE = relationships =20 - General agreement is routing info should be split and current proposal = will be sent to the list for Kenichi, and working groups, review.=20 =20 =20 =3D=3D Conclusions =3D=3D =20 =20 - A number of resolutions have been agreed and will be updated in the = I-D =20 - Chairs would like to see revised I-D based on the agreed points =20 - Plan to have another interim call at the end of January (2016) =20 - Chairs to add new tracker items, including security for future = discussion.=20 =20 =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 From nobody Tue Feb 23 21:09:11 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8361B4537 for ; Tue, 23 Feb 2016 21:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.048 X-Spam-Level: *** X-Spam-Status: No, score=3.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=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 ML95EhVEyfNm for ; Tue, 23 Feb 2016 21:09:02 -0800 (PST) Received: from post-send.kddi.com (athena2.kddi.com [27.90.165.195]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0F41B4536 for ; Tue, 23 Feb 2016 21:09:02 -0800 (PST) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id C919AE001A; Wed, 24 Feb 2016 14:09:00 +0900 (JST) Received: from LTMC2146.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Wed, 24 Feb 2016 14:09:00 +0900 Received: from LTMC2146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 9AEF630005D; Wed, 24 Feb 2016 14:09:00 +0900 (JST) Received: from LTMC2153.kddi.com (post-incheck [10.206.0.239]) by LTMC2146.kddi.com (Postfix) with ESMTP id 89E25300051; Wed, 24 Feb 2016 14:09:00 +0900 (JST) Received: from LTMC2153.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2153.kddi.com with ESMTP id u1O590n6028166; Wed, 24 Feb 2016 14:09:00 +0900 Received: from LTMC2153.kddi.com.mid_59959323 (localhost.localdomain [127.0.0.1]) by LTMC2153.kddi.com with ESMTP id u1O4wtlO016866; Wed, 24 Feb 2016 13:58:56 +0900 X-SA-MID: 59959323 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Wed, 24 Feb 2016 13:58:55 +0900 From: "Ogaki, Kenichi" To: "'Aijun Wang'" <13301168517@189.cn>, , References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> <004101d16e97$e0692800$a13b7800$@kddi.com> <002d01d16e9f$88e66130$9ab32390$@cn> In-Reply-To: <002d01d16e9f$88e66130$9ab32390$@cn> Date: Wed, 24 Feb 2016 13:58:55 +0900 Message-ID: <006701d16ec0$1063fee0$312bfca0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+JsdlYZ7cvi/Fz8JTONaqj4LvoQKs2aO/AYjUCCUDWny42J2kqByg Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 05:09:07 -0000 Hi Aijun, >1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. > >[KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. >For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. >Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. >In that sense, I basically prefer the current model. >[Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. >There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement? If a physical customer site connects to two different vpns in this case, = the customer must input or update the information about the (physical) = site duplicately per vpn-svc. This may cause misconfiguration and bother = our customers. Another concern is the inconsistency with accounting/charging model, = when an operator charges the fee for physical access, it becomes = inconsistent with the charging model. When we does a traffic accounting = not only for logical access per vpn, but also for physical access, we = must always take care of the existence of different vpn-svc with the = same physical access in order to trigger a polling traffic counter of = the interface on PE. I understand it depends on each operator's service definition, vpn = specific or site specific, as Stephane wrote. To accommodate these different requirements, I think the loose coupled = model between the components, vpn and site, seems better. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 10:06 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Please see the reply inline. Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network = Research and Operation Support Department -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 8:11 AM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, See comments inline, please. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 18, 2016 1:12 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Stephane and Ogaki: =20 I suggested we put the "extranet-vpn-policy" under the list "vpn-svc" = directly, not in the container "vpn-policy" that is now under the list = "sites" in current model.=20 [KO]Like this? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } ... } ... } [Aijun Wang]: Yes. This can solve the initial scenario that proposed by Kenichi at the = beginning of our discussion. When the orchestrator receives the = information defined in "extranet-vpn-policy", it can allocate new = route-target for the involved VPNs and set them in the configuration = stanza of each router. =20 For the relationship of list "vpn-svc" and list "sites", I still suggest = we put the list "site" under the "vpn-svc", the reason for doing this is = as below: 1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. [KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. In that sense, I basically prefer the current model. [Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement?=20 2. The attributes of "sites", such as "maximum-routes", "security", = "service", "routing-protocols","site-netwok-accesses" etc. are all = service/site role related, that is to say, if the site role changed, all = of these attributed may be changed accordingly. [KO] I basically agree. The attributes tied to a whole vpn and globally = applied to all the sites under the vpn should be defined with the vpn = definition. 3.For container "vpn policy" that under list "sites" in current model, = there are two information defined, one is "filter" for prefix filtering, = another is "site-role". I suggest we split it, put the leaf "site-role" = under leaf "site-id" directly, and change the name of "vpn-policy" to = "site-prefix-policy".=20 =20 The final suggest structure of the L3VPN yang model will be look like = the bellow, I underline the changed positions from the current l3vpn = Yang Model =20 Container L3vpn-svc List vpn-svc Leaf vpn-id Leaf customer-name Leaf topology List extranet-vpn-policy Container cloud-access List multicast Leaf mpls List transport-contraints =20 List sites Leaf site-id Leaf site-role leaf apply-template ... ... ... ... Container managent Container site-prefix-policy Container maximum-routes Container security ... ... ... ... Site-network-access=20 =20 =20 Whether is it more reasonable?=20 =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute=20 Network Research and Operation Support Department =20 =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 18, 2016 9:08 AM To: l3sm@ietf.org Subject: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday = L3SM interim session =20 Hi Stephane and All, =20 As for issue #10 itself, the following solution can be acceptable for = us. =20 >One proposal could be to not call this VPN policy, but creating a >container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). =20 What model is in your mind? I can't see what ""extranet-vpn-policy" at = vpn" means. Like this? =20 ... 1 VPN1 VPN2 ... =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of stephane.litkowski@orange.com = =20 Sent: Monday, December 07, 2015 11:45 PM To: Ogaki, Kenichi; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi Kenichi, =20 Regarding your proposal of having a simple VPN policy in the vpn-svc = container, I do see an issue. One of the key point of the VPN policy is = to express the role of the site in the target VPN topology. If we do a vpn policy at VPN level, we cannot anymore describe site = roles in the target VPN which causes an issue. In an ideal world where all VPNs are any to any, the site role is always = the same and there is no issue, but let's think about someone trying to = use the vpn-policy (at vpn level) to connect to a Hub & Spoke VPN, how = do you deduce the roles of the sites ? =20 One proposal could be to not call this VPN policy, but creating a = container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). This means that the usage is really limited to "simple" = extranet-vpns and it does not replace nor compete with the VPN policy at = site level. =20 Could it be a good compromise ? =20 Stephane =20 =20 -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com = ] Sent: Saturday, December 05, 2015 06:23 To: LITKOWSKI Stephane SCE/OINIS; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear Stephane and All, =20 I don't say that sites *must* move under vpn-svc because I understand = stephane's use case. But we already have vpn-svc and some parameters under this are globally = applied to all the sites even in the current model. =20 It depends on operator's use case which is site-oriented or vpn-oriented = service. Our service is vpn-oriented, site has the native VPN. Then, I would just = like you to allow other global options to vpn-svc. =20 Thanks, Kenichi =20 -----Original Message----- From: stephane.litkowski@orange.com = = [mailto:stephane.litkowski@orange.com = ] Sent: Friday, December 04, 2015 8:17 PM To: Aijun Wang; 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi, =20 I'm against this proposal, as I do not want to create any dependency = between a particular VPN and a list of sites. A site can belong to multiple VPNs with any kind of topology, if we = attach the site to a single VPN, we come back to the notion of "native = VPN" we had at the beginning of the model which was hard to understand = and so was removed. =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Aijun Wang Sent: Friday, December 04, 2015 02:44 To: 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear all: =20 Can we put the list "sites" within the list "vpn-svc", and define the = general vpn policy for all sites that within the corresponding vpn = service instance? If doing so, some entries within the current list "sites" can also be = dragged out for general usual purposes, for example, "maximum-routes", = "security" etc. These parameters are often all same for every site = within one VPN service instance.=20 =20 If some sites have special requirements, we can achieve this by using = some special "site-vpn-policy" within the corresponding site definition. Is this more acceptable for customers? =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute Intelligent = Network Product Line =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Ogaki, Kenichi Sent: Friday, December 04, 2015 9:02 AM To: 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear All, =20 It was good having discussion. =20 As for issue#10, the objective and problem we discussed in the meeting = as follows. =20 The objective is to provide per-VPN extranet service which connects two = different VPNs (e.g. VPN1 and VPN2). It means that any sites in VPN1 can = access to any sites in VPN2. The problem is that the current model must update vpn-policy under all = the sites belong to these two VPNs in order to offer this service. = Especially when this model is used as a customer self-control API, it's = not good idea to require customers to update the information of all the = sites. (It's not abstracted way, a service model should provide what the = consumer wants, not how.) If a service or customer requires to control = per-site vpn-policy, that of current model should be used without = setting per-VPN vpn-polity. It depends on each operator's service. Stephane proposed to use apply-template, but it still cannot solve the = problem. When each VPN already has a large number of sites and want to = connect each other for the first time, both VPNs must update these sites = to apply apply-template on the current model. =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Qin Wu Sent: Friday, December 04, 2015 12:42 AM To: l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: [L3sm] L3SM interim meeting minutes on Thursday L3SM interim = session =20 Hi all: =20 =20 Below is the initial version of draft minutes for Thursday L3SM WG = interim session. =20 Thanks Dan to help take minutes. =20 Folks, please let us know if you have any correction. =20 =20 -Qin =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =20 L3SM Working Group Virtual Interim Meeting=20 =20 Thursday December 5th, 2015. 8am East Coast Time (New York) =20 =20 BLUE SHEET =20 =20 Name | Affiliation =20 ------------------------+----------------------------------------------- ------------------------+- =20 Adrian Farrel | Old Dog Consulting =20 Qin Wu | Huawei Technologies =20 Stephane Litkowski | Orange =20 Luis Tomotaki | Verizon =20 Daniel King | Old Dog Consulting =20 Susan Hares | Huawei Technologies =20 Scott Mansfield | Ericsson =20 Gu Rong | China Mobile=20 =20 Kenichi Ogaki | KDDI =20 Aijun Wang | China Telecom =20 Victor Santos | Ericsson =20 Ignas Bagdonas |=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 MINUTES =20 =20 * Meting logiistics = https://mailarchive.ietf.org/arch/msg/l3sm/SJub1aHVQGOQW6rWhthX0fB8Ac8 = = =20 =20 * Meeting materials = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/proceedings.html= = =20 =20 * Etherpad for minutes (this page) = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03 = =20 =20 * Jabber using l3sm@jabber.ietf.org =20 =20 * Blue sheet = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03-bluesheet = = =20 =20 =20 Agendaa =20 - Administrivia (Note Well, etc). a =20 - Introduction =20 - Open Issues for YANG Data Model for L3VPNservice delivery = (draft-ietf-l3sm-l3vpn-servicemodel) =20 o Open Issues discussion and resolution=E2=80=93 = http://trac.tools.ietf.org/wg/l3sm/trac/report/1 = =20 =20 =20 For a full list of issues and resolution proposals please see: = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/slides/slides-in= terim-2015-l3sm-1-2.pdf = =20 =20 =20 Issue#1: When customer-nat-address is used =20 Resolution #1: Leaf used when NAT is required to access cloud VPN and = customer wants to use its ownIP address. If provider provides the public = IP,no need to use the leaf =20 Status #1: Closed Pending I-D text review. =20 =20 Discussion on #1:=20 =20 =20 Aijun asks for more description in the YANG model itself =20 Stephane shows current model =20 Agreed OK =20 =20 Issue#2 : Identify l3vpn svc using id or name or both =20 Resolution #2: ID is a string, as per other properties in the model =20 Status #2: Closed =20 Discussion on #2:=20 =20 =20 Agreed OK =20 =20 Issue#3: M to N availability support =20 Resolution #3: Modeling sites using a list with a priority, so include = access list with a priority. =20 Status #3: =20 Discussion on #3:=20 =20 =20 Qin was asking that M to N availability is supported with access and = priority number.=20 =20 Stephane stated this is suppoted. This new proposal also supports = multiple sites, as a list. =20 Qin also asked if Group I-D was no longer needed, which it is not. Also = good solution supported by other operators. =20 Stephane asked if four priorities was enough, or if more were needed.=20 =20 =20 Re: Containers/Properties for Network Access Configuration - = Conclusions? =20 =20 o Location - Different site I-D? =20 o QoS Policy - Per network access link, or site information? Would QoS = (cost) be different per accesslink or site? Example of Primary and = Backup links given.=20 =20 o Bandwidth - Moved to access link group=20 =20 o Maximum Routes -=20 =20 Security, routing, and services are duplicated with inheritance =20 =20 =20 Issue#4: site-service-cloud access as grouping =20 Resolution #4 Already resilved as a separate grouping =20 Status #4: Closed =20 Discussion on #4:=20 =20 =20 Issue#5: Multicast support as raised by Eric Rosen =20 Resolution #5: : New "provider managed" property, and in Site Properties = "property-type" added =20 Status #5: Solution proposed.=20 =20 Discussion on #5:=20 =20 =20 Stephane will proviode new property proposals will be provided to Eric = for review.=20 =20 =20 Issue#6: Inventory operational state =20 Resolution #6: Include a new container for inventory state, or an RPC = call (sitting above the service orchestrator) to retrieve inventory = state.=20 =20 Status #6: Need to propose to the WG and agree solution. =20 Discussion on #6:=20 =20 =20 Luis asked would this info be collected from provision state? Stephane = suggested this would not be availible.=20 =20 Adrian observed that the code used to convert the model into a service = request may not utilise this inventory information capability. Sue = mentioned that others have mentioned by a vendor that it would be useful = to have the ability to configure inventory state. This should be = clarified by the operators.=20 =20 =20 Stephane to take proposals to list and ask anyone who is interested in = having the feature to suggest text. =20 =20 =20 Issue#7: Generic VAS - do we need to create a generic VAS container as = VAS are popular in L3VPNs? =20 Resolution #7: Separate from L3SM =20 Status #7: Closed =20 Discussion on #7:=20 =20 =20 Gu Rong highlighted Generic VAS model which was presented at IETF 94.=20 =20 =20 Issue#8: Who keeps site locationinformation? =20 Resolution #8: Text has been fixed =20 Status #8: Closed =20 Discussion on #8:=20 =20 =20 =20 Issue#9: Do we need to model transport constraints, such as: jitter, = disjoint, path diversity? =20 Resolution #9: Propose a "transport-constraint" group with = "constraint-type", "constraint-value" and "constraint-list" (composed of = type and values) =20 Status #9: Authors to propose the resolution in the I-D and provide to = the WG =20 Discussion on #9: =20 =20 =20 =20 Luis mentioned that they have multicast transport (multiple sites) and = bi-directional traffic applications (financial) that will require = transport constraints =20 =20 Duplicate transport constraints for unicast and multicast to give = options for separate configuration. =20 Keep single list entries for each src/dst pair even in the multicast = variant. =20 =20 DO we need to support multiple constraints or just have a single = composite (of multiple constraints), have the ability to specify a = constraint-list? =20 Aijun prfers list of constraints and meeting agrees this is OK =20 =20 What constraints to offer? =20 Latency =20 Path diversty =20 Site diversty =20 Jitter =20 Class of service was proposed but rejected =20 =20 Luis highlighted they have a current implementation that uses the = similar proposal. Luis also mentioned that site diversity might also be = required, would this be achievable =20 =20 =20 Issue#10: VPN "merging" =20 Resolution #10: =20 =20 Status #10: =20 Discussion on #10: =20 =20 =20 VPN is a per site property.=20 =20 - A site can belong tomultiple VPNs =20 - How to handle merging of two VPNs? =20 - Is this an issue the service model has to deal with? =20 =20 If VPN merging is required to be seamless, then this would be device = specific and not service model related. =20 =20 =20 "Merging" is a confusing term. The objective is NOT to merge VPN1 and = VPN2. =20 The objective is to provide an extranet so that some sites in VPN1 can = connect to some sites in VPN2 for some traffic. =20 This can be solved using a per-site property. =20 =20 Action: Need to update this issue to make it clear what function was = being discussed, also Stephane will send options to the working group- = list.=20 =20 We are specifically looking for people who offer extranet connection = between sites from different VPNs =20 =20 =3D=3D Other Issues =3D=3D =20 =20 =20 Modeling Customer Specific Info =20 - Create appropiate containers for Provider Edge and Customer Site = routers =20 - The current model contains routing parametres that refer to CE and PE = relationships =20 - General agreement is routing info should be split and current proposal = will be sent to the list for Kenichi, and working groups, review.=20 =20 =20 =3D=3D Conclusions =3D=3D =20 =20 - A number of resolutions have been agreed and will be updated in the = I-D =20 - Chairs would like to see revised I-D based on the agreed points =20 - Plan to have another interim call at the end of January (2016) =20 - Chairs to add new tracker items, including security for future = discussion.=20 =20 =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Wed Feb 24 00:44:18 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C386A1B481A for ; Wed, 24 Feb 2016 00:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.048 X-Spam-Level: *** X-Spam-Status: No, score=3.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=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 MkbWTAXfDvWD for ; Wed, 24 Feb 2016 00:44:12 -0800 (PST) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id A1EA71B4818 for ; Wed, 24 Feb 2016 00:44:11 -0800 (PST) Received: from LTMC2122.kddi.com (LTMC2122.kddi.com [10.206.0.63]) by post-send.kddi.com (KDDI Mail) with ESMTP id 771ECE00CC; Wed, 24 Feb 2016 17:44:10 +0900 (JST) Received: from LTMC2146.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2122.kddi.com with ESMTP; Wed, 24 Feb 2016 17:44:10 +0900 Received: from LTMC2146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 44F0730005D; Wed, 24 Feb 2016 17:44:10 +0900 (JST) Received: from LTMC2151.kddi.com (post-incheck [10.206.0.239]) by LTMC2146.kddi.com (Postfix) with ESMTP id 39AFE300051; Wed, 24 Feb 2016 17:44:10 +0900 (JST) Received: from LTMC2151.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u1O8i9Ec031857; Wed, 24 Feb 2016 17:44:10 +0900 Received: from LTMC2151.kddi.com.mid_32614646 (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u1O8Y8lc016508; Wed, 24 Feb 2016 17:34:08 +0900 X-SA-MID: 32614646 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Wed, 24 Feb 2016 17:34:08 +0900 From: "Ogaki, Kenichi" To: "'Aijun Wang'" <13301168517@189.cn>, , References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> <004101d16e97$e0692800$a13b7800$@kddi.com> <002d01d16e9f$88e66130$9ab32390$@cn> <006701d16ec0$1063fee0$312bfca0$@kddi.com> <004301d16ec8$270d9090$7528b1b0$@cn> In-Reply-To: <004301d16ec8$270d9090$7528b1b0$@cn> Date: Wed, 24 Feb 2016 17:34:08 +0900 Message-ID: <008401d16ede$20cee4c0$626cae40$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+JsdlYZ7cvi/Fz8JTONaqj4LvoQKs2aO/AYjUCCUDWny42AHbJwT5AVTH19qdi21tIA== Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 08:44:16 -0000 Hi Aijun, >Within the current Yang model, it is not loose coupled for the vpn and = sites. Every=20 >site is associated with at least one vpn-policy entry. I wanted to mean by loose coupling that vpn and site should be = structurally at the same level. This means that a kind of graph = structure is better than a hierarchical structure. In a VPN service, it=E2=80=99s natural that a site must belong to at = least one vpn. >The reason that I prefer the "vpn-->site" structure to "site-->vpn" = structure is=20 >that the majority of containers within lists "sites" are vpn-related, = as you also=20 >confirmed this. >From the configuration viewpoint in the current model, the link = information between vpn and site can be configurable only in sites. = That's vpn-policy. This is reasonable to avoid the inconsistency in the case that both can = be configurable.=20 This information, which site belongs to which vpn, may be able to be = moved under vpn-svc as a list, but I don't think the necessity. It may = be useful to define the op-state under vpn-svc as discussed in issue#6. I agreed with the principle what you wrote, but I didn't carefully = discuss each container should be under vpn-svc or site. IMO, if any container is placed inappropriately, we should just move it = to the appropriate place. It's different problem from the model = structure discussion. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 2:57 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Within the current Yang model, it is not loose coupled for the vpn and = sites. Every site is associated with at least one vpn-policy entry.=20 The reason that I prefer the "vpn-->site" structure to "site-->vpn" = structure is that the majority of containers within lists "sites" are = vpn-related, as you also confirmed this. Then it is not enough in = current Yang model to correlate only the "vpn-policy" container to = different vpn id. And on the other way, we can also use the site-template to lessen the = burden of the customer configuration, as that done in current Yang = model. -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com]=20 Sent: Wednesday, February 24, 2016 12:59 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. > >[KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. >For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. >Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. >In that sense, I basically prefer the current model. >[Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. >There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement? If a physical customer site connects to two different vpns in this case, = the customer must input or update the information about the (physical) = site duplicately per vpn-svc. This may cause misconfiguration and bother = our customers. Another concern is the inconsistency with accounting/charging model, = when an operator charges the fee for physical access, it becomes = inconsistent with the charging model. When we does a traffic accounting = not only for logical access per vpn, but also for physical access, we = must always take care of the existence of different vpn-svc with the = same physical access in order to trigger a polling traffic counter of = the interface on PE. I understand it depends on each operator's service definition, vpn = specific or site specific, as Stephane wrote. To accommodate these different requirements, I think the loose coupled = model between the components, vpn and site, seems better. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 10:06 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Please see the reply inline. Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network = Research and Operation Support Department -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 8:11 AM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, See comments inline, please. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 18, 2016 1:12 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Stephane and Ogaki: =20 I suggested we put the "extranet-vpn-policy" under the list "vpn-svc" = directly, not in the container "vpn-policy" that is now under the list = "sites" in current model.=20 [KO]Like this? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } ... } ... } [Aijun Wang]: Yes. This can solve the initial scenario that proposed by Kenichi at the = beginning of our discussion. When the orchestrator receives the = information defined in "extranet-vpn-policy", it can allocate new = route-target for the involved VPNs and set them in the configuration = stanza of each router. =20 For the relationship of list "vpn-svc" and list "sites", I still suggest = we put the list "site" under the "vpn-svc", the reason for doing this is = as below: 1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. [KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. In that sense, I basically prefer the current model. [Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement?=20 2. The attributes of "sites", such as "maximum-routes", "security", = "service", "routing-protocols","site-netwok-accesses" etc. are all = service/site role related, that is to say, if the site role changed, all = of these attributed may be changed accordingly. [KO] I basically agree. The attributes tied to a whole vpn and globally = applied to all the sites under the vpn should be defined with the vpn = definition. 3.For container "vpn policy" that under list "sites" in current model, = there are two information defined, one is "filter" for prefix filtering, = another is "site-role". I suggest we split it, put the leaf "site-role" = under leaf "site-id" directly, and change the name of "vpn-policy" to = "site-prefix-policy".=20 =20 The final suggest structure of the L3VPN yang model will be look like = the bellow, I underline the changed positions from the current l3vpn = Yang Model =20 Container L3vpn-svc List vpn-svc Leaf vpn-id Leaf customer-name Leaf topology List extranet-vpn-policy Container cloud-access List multicast Leaf mpls List transport-contraints =20 List sites Leaf site-id Leaf site-role leaf apply-template ... ... ... ... Container managent Container site-prefix-policy Container maximum-routes Container security ... ... ... ... Site-network-access=20 =20 =20 Whether is it more reasonable?=20 =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute=20 Network Research and Operation Support Department =20 =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 18, 2016 9:08 AM To: l3sm@ietf.org Subject: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday = L3SM interim session =20 Hi Stephane and All, =20 As for issue #10 itself, the following solution can be acceptable for = us. =20 >One proposal could be to not call this VPN policy, but creating a >container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). =20 What model is in your mind? I can't see what ""extranet-vpn-policy" at = vpn" means. Like this? =20 ... 1 VPN1 VPN2 ... =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of stephane.litkowski@orange.com = =20 Sent: Monday, December 07, 2015 11:45 PM To: Ogaki, Kenichi; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi Kenichi, =20 Regarding your proposal of having a simple VPN policy in the vpn-svc = container, I do see an issue. One of the key point of the VPN policy is = to express the role of the site in the target VPN topology. If we do a vpn policy at VPN level, we cannot anymore describe site = roles in the target VPN which causes an issue. In an ideal world where all VPNs are any to any, the site role is always = the same and there is no issue, but let's think about someone trying to = use the vpn-policy (at vpn level) to connect to a Hub & Spoke VPN, how = do you deduce the roles of the sites ? =20 One proposal could be to not call this VPN policy, but creating a = container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). This means that the usage is really limited to "simple" = extranet-vpns and it does not replace nor compete with the VPN policy at = site level. =20 Could it be a good compromise ? =20 Stephane =20 =20 -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com = ] Sent: Saturday, December 05, 2015 06:23 To: LITKOWSKI Stephane SCE/OINIS; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear Stephane and All, =20 I don't say that sites *must* move under vpn-svc because I understand = stephane's use case. But we already have vpn-svc and some parameters under this are globally = applied to all the sites even in the current model. =20 It depends on operator's use case which is site-oriented or vpn-oriented = service. Our service is vpn-oriented, site has the native VPN. Then, I would just = like you to allow other global options to vpn-svc. =20 Thanks, Kenichi =20 -----Original Message----- From: stephane.litkowski@orange.com = = [mailto:stephane.litkowski@orange.com = ] Sent: Friday, December 04, 2015 8:17 PM To: Aijun Wang; 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi, =20 I'm against this proposal, as I do not want to create any dependency = between a particular VPN and a list of sites. A site can belong to multiple VPNs with any kind of topology, if we = attach the site to a single VPN, we come back to the notion of "native = VPN" we had at the beginning of the model which was hard to understand = and so was removed. =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Aijun Wang Sent: Friday, December 04, 2015 02:44 To: 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear all: =20 Can we put the list "sites" within the list "vpn-svc", and define the = general vpn policy for all sites that within the corresponding vpn = service instance? If doing so, some entries within the current list "sites" can also be = dragged out for general usual purposes, for example, "maximum-routes", = "security" etc. These parameters are often all same for every site = within one VPN service instance.=20 =20 If some sites have special requirements, we can achieve this by using = some special "site-vpn-policy" within the corresponding site definition. Is this more acceptable for customers? =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute Intelligent = Network Product Line =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Ogaki, Kenichi Sent: Friday, December 04, 2015 9:02 AM To: 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear All, =20 It was good having discussion. =20 As for issue#10, the objective and problem we discussed in the meeting = as follows. =20 The objective is to provide per-VPN extranet service which connects two = different VPNs (e.g. VPN1 and VPN2). It means that any sites in VPN1 can = access to any sites in VPN2. The problem is that the current model must update vpn-policy under all = the sites belong to these two VPNs in order to offer this service. = Especially when this model is used as a customer self-control API, it's = not good idea to require customers to update the information of all the = sites. (It's not abstracted way, a service model should provide what the = consumer wants, not how.) If a service or customer requires to control = per-site vpn-policy, that of current model should be used without = setting per-VPN vpn-polity. It depends on each operator's service. Stephane proposed to use apply-template, but it still cannot solve the = problem. When each VPN already has a large number of sites and want to = connect each other for the first time, both VPNs must update these sites = to apply apply-template on the current model. =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Qin Wu Sent: Friday, December 04, 2015 12:42 AM To: l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: [L3sm] L3SM interim meeting minutes on Thursday L3SM interim = session =20 Hi all: =20 =20 Below is the initial version of draft minutes for Thursday L3SM WG = interim session. =20 Thanks Dan to help take minutes. =20 Folks, please let us know if you have any correction. =20 =20 -Qin =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =20 L3SM Working Group Virtual Interim Meeting=20 =20 Thursday December 5th, 2015. 8am East Coast Time (New York) =20 =20 BLUE SHEET =20 =20 Name | Affiliation =20 ------------------------+----------------------------------------------- ------------------------+- =20 Adrian Farrel | Old Dog Consulting =20 Qin Wu | Huawei Technologies =20 Stephane Litkowski | Orange =20 Luis Tomotaki | Verizon =20 Daniel King | Old Dog Consulting =20 Susan Hares | Huawei Technologies =20 Scott Mansfield | Ericsson =20 Gu Rong | China Mobile=20 =20 Kenichi Ogaki | KDDI =20 Aijun Wang | China Telecom =20 Victor Santos | Ericsson =20 Ignas Bagdonas |=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 MINUTES =20 =20 * Meting logiistics = https://mailarchive.ietf.org/arch/msg/l3sm/SJub1aHVQGOQW6rWhthX0fB8Ac8 = = =20 =20 * Meeting materials = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/proceedings.html= = =20 =20 * Etherpad for minutes (this page) = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03 = =20 =20 * Jabber using l3sm@jabber.ietf.org =20 =20 * Blue sheet = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03-bluesheet = = =20 =20 =20 Agendaa =20 - Administrivia (Note Well, etc). a =20 - Introduction =20 - Open Issues for YANG Data Model for L3VPNservice delivery = (draft-ietf-l3sm-l3vpn-servicemodel) =20 o Open Issues discussion and resolution=E2=80=93 = http://trac.tools.ietf.org/wg/l3sm/trac/report/1 = =20 =20 =20 For a full list of issues and resolution proposals please see: = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/slides/slides-in= terim-2015-l3sm-1-2.pdf = =20 =20 =20 Issue#1: When customer-nat-address is used =20 Resolution #1: Leaf used when NAT is required to access cloud VPN and = customer wants to use its ownIP address. If provider provides the public = IP,no need to use the leaf =20 Status #1: Closed Pending I-D text review. =20 =20 Discussion on #1:=20 =20 =20 Aijun asks for more description in the YANG model itself =20 Stephane shows current model =20 Agreed OK =20 =20 Issue#2 : Identify l3vpn svc using id or name or both =20 Resolution #2: ID is a string, as per other properties in the model =20 Status #2: Closed =20 Discussion on #2:=20 =20 =20 Agreed OK =20 =20 Issue#3: M to N availability support =20 Resolution #3: Modeling sites using a list with a priority, so include = access list with a priority. =20 Status #3: =20 Discussion on #3:=20 =20 =20 Qin was asking that M to N availability is supported with access and = priority number.=20 =20 Stephane stated this is suppoted. This new proposal also supports = multiple sites, as a list. =20 Qin also asked if Group I-D was no longer needed, which it is not. Also = good solution supported by other operators. =20 Stephane asked if four priorities was enough, or if more were needed.=20 =20 =20 Re: Containers/Properties for Network Access Configuration - = Conclusions? =20 =20 o Location - Different site I-D? =20 o QoS Policy - Per network access link, or site information? Would QoS = (cost) be different per accesslink or site? Example of Primary and = Backup links given.=20 =20 o Bandwidth - Moved to access link group=20 =20 o Maximum Routes -=20 =20 Security, routing, and services are duplicated with inheritance =20 =20 =20 Issue#4: site-service-cloud access as grouping =20 Resolution #4 Already resilved as a separate grouping =20 Status #4: Closed =20 Discussion on #4:=20 =20 =20 Issue#5: Multicast support as raised by Eric Rosen =20 Resolution #5: : New "provider managed" property, and in Site Properties = "property-type" added =20 Status #5: Solution proposed.=20 =20 Discussion on #5:=20 =20 =20 Stephane will proviode new property proposals will be provided to Eric = for review.=20 =20 =20 Issue#6: Inventory operational state =20 Resolution #6: Include a new container for inventory state, or an RPC = call (sitting above the service orchestrator) to retrieve inventory = state.=20 =20 Status #6: Need to propose to the WG and agree solution. =20 Discussion on #6:=20 =20 =20 Luis asked would this info be collected from provision state? Stephane = suggested this would not be availible.=20 =20 Adrian observed that the code used to convert the model into a service = request may not utilise this inventory information capability. Sue = mentioned that others have mentioned by a vendor that it would be useful = to have the ability to configure inventory state. This should be = clarified by the operators.=20 =20 =20 Stephane to take proposals to list and ask anyone who is interested in = having the feature to suggest text. =20 =20 =20 Issue#7: Generic VAS - do we need to create a generic VAS container as = VAS are popular in L3VPNs? =20 Resolution #7: Separate from L3SM =20 Status #7: Closed =20 Discussion on #7:=20 =20 =20 Gu Rong highlighted Generic VAS model which was presented at IETF 94.=20 =20 =20 Issue#8: Who keeps site locationinformation? =20 Resolution #8: Text has been fixed =20 Status #8: Closed =20 Discussion on #8:=20 =20 =20 =20 Issue#9: Do we need to model transport constraints, such as: jitter, = disjoint, path diversity? =20 Resolution #9: Propose a "transport-constraint" group with = "constraint-type", "constraint-value" and "constraint-list" (composed of = type and values) =20 Status #9: Authors to propose the resolution in the I-D and provide to = the WG =20 Discussion on #9: =20 =20 =20 =20 Luis mentioned that they have multicast transport (multiple sites) and = bi-directional traffic applications (financial) that will require = transport constraints =20 =20 Duplicate transport constraints for unicast and multicast to give = options for separate configuration. =20 Keep single list entries for each src/dst pair even in the multicast = variant. =20 =20 DO we need to support multiple constraints or just have a single = composite (of multiple constraints), have the ability to specify a = constraint-list? =20 Aijun prfers list of constraints and meeting agrees this is OK =20 =20 What constraints to offer? =20 Latency =20 Path diversty =20 Site diversty =20 Jitter =20 Class of service was proposed but rejected =20 =20 Luis highlighted they have a current implementation that uses the = similar proposal. Luis also mentioned that site diversity might also be = required, would this be achievable =20 =20 =20 Issue#10: VPN "merging" =20 Resolution #10: =20 =20 Status #10: =20 Discussion on #10: =20 =20 =20 VPN is a per site property.=20 =20 - A site can belong tomultiple VPNs =20 - How to handle merging of two VPNs? =20 - Is this an issue the service model has to deal with? =20 =20 If VPN merging is required to be seamless, then this would be device = specific and not service model related. =20 =20 =20 "Merging" is a confusing term. The objective is NOT to merge VPN1 and = VPN2. =20 The objective is to provide an extranet so that some sites in VPN1 can = connect to some sites in VPN2 for some traffic. =20 This can be solved using a per-site property. =20 =20 Action: Need to update this issue to make it clear what function was = being discussed, also Stephane will send options to the working group- = list.=20 =20 We are specifically looking for people who offer extranet connection = between sites from different VPNs =20 =20 =3D=3D Other Issues =3D=3D =20 =20 =20 Modeling Customer Specific Info =20 - Create appropiate containers for Provider Edge and Customer Site = routers =20 - The current model contains routing parametres that refer to CE and PE = relationships =20 - General agreement is routing info should be split and current proposal = will be sent to the list for Kenichi, and working groups, review.=20 =20 =20 =3D=3D Conclusions =3D=3D =20 =20 - A number of resolutions have been agreed and will be updated in the = I-D =20 - Chairs would like to see revised I-D based on the agreed points =20 - Plan to have another interim call at the end of January (2016) =20 - Chairs to add new tracker items, including security for future = discussion.=20 =20 =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 _______________________________________________ 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 From nobody Wed Feb 24 18:34:23 2016 Return-Path: <13301168517@189.cn> X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0DD1B2E0C for ; Wed, 24 Feb 2016 18:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.207 X-Spam-Level: ** X-Spam-Status: No, score=2.207 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_LOCAL_DIGITS=0.001, FROM_LOCAL_HEX=0.006, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 JdtAeV7bIprV for ; Wed, 24 Feb 2016 18:34:21 -0800 (PST) Received: from 189.cn (ptr.189.cn [121.14.53.131]) by ietfa.amsl.com (Postfix) with ESMTP id 454691B2DFF for ; Wed, 24 Feb 2016 18:34:20 -0800 (PST) HMM_SOURCE_IP: 10.64.8.34:40690.79133122 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.77 (unknown [10.64.8.34]) by 189.cn (HERMES) with ESMTP id E101D4600CE for ; Thu, 25 Feb 2016 10:34:15 +0800 (CST) Received: from ctbriwangaij ([219.142.69.77]) by zm-as4(MEDUSA 0.0.0.0) with ESMTP id 5b92da7f-09a1-44b6-baf4-a6f5113d9634 for l3sm@ietf.org; Thu Feb 25 10:34:17 2016 0/X-Total-Score: 0: X-FILTER-SCORE: to=<8d54948e618a8695874f909388>, score=<1456367657MMFMMVMjFVJo+U8wMMMMMjj2jjKjT2KQgrXzAjjjjjTj> X-REAL-FROM: 13301168517@189.cn X-Receive-IP: 219.142.69.77 From: "Aijun Wang" <13301168517@189.cn> To: Date: Thu, 25 Feb 2016 10:34:25 +0800 Message-ID: <005d01d16f75$1107ddc0$33179940$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01D16FB8.1F2B1DC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdFvcZ2IgU8kJ02yRIulOO8e+OsH+QAA1zAw Content-Language: zh-cn Archived-At: Subject: [L3sm] Additional Issues---site's parameter relation with specific vpn X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 02:34:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005E_01D16FB8.1F2B1DC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, L3SMer: With the discussion about the current L3VPN yang model, we found there is another additional issue needed to be solved. This issue will influence the design of L3SM Yang structure as well. Issue description: In current L3VPN yang model, we define the site's various parameters via several container, such as "location", "site-diversity","management","vpn-policy","maximum-routes","security","serv ice","routing-protocol","site-network-accesses" etc. For these containers, only the "location" is determined and has no relation with the specific vpn id, other containers are all related with the specific vpn id. That is to say, if the vpn is different, the "site-diversity","management","vpn-policy","maximum-routes","security","serv ice","routing-protocol","site-network-accesses" container will have different values, but in current Yang model, only the "vpn-policy" has relationship with the vpn-id. Solution proposal: Put the site definition or reference within the list "vpn-svc", please see https://mailarchive.ietf.org/arch/msg/l3sm/lB4HbUVczwyygAScPeh4tV0EBRo So, what your consideration for this issue and solution proposal? Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network Research and Operation Support Department ------=_NextPart_000_005E_01D16FB8.1F2B1DC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, = L3SMer:

 

With the discussion about the current L3VPN yang model, we = found there is another additional issue needed to be solved. This issue = will influence the design of L3SM Yang structure as = well.

 

Issue description: In current L3VPN yang model, we define = the site’s various parameters via several = container,

such as “location”, = “site-diversity”,”management”,”vpn-policy&#= 8221;,”maximum-routes”,”security”,”service&= #8221;,”routing-protocol”,”site-network-accesses”= etc. For these containers, only the “location” is = determined and has no relation with the specific vpn id, other = containers are all related with the specific vpn = id.

That is to say, if the vpn is different, the = “site-diversity”,”management”,”vpn-policy&#= 8221;,”maximum-routes”,”security”,”service&= #8221;,”routing-protocol”,”site-network-accesses”= container will have different values, but in current Yang model, only = the “vpn-policy” has relationship with the = vpn-id.

 

Solution proposal: Put the site definition or reference = within the list “vpn-svc”, please see https://mailarchive.ietf.org/arch/msg/l3sm/lB4HbUVczwyygAScPeh4tV0= EBRo

 

So, what your consideration for this issue and solution = proposal?

 

Best = Regards.

 =

Aijun = Wang

 =

China = Telecom Corporation Limited Beijing Research Ins= titute 

Network = Research and Operation Support Department

 

------=_NextPart_000_005E_01D16FB8.1F2B1DC0-- From nobody Wed Feb 24 19:36:00 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEB61B2FFA for ; Wed, 24 Feb 2016 19:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.048 X-Spam-Level: *** X-Spam-Status: No, score=3.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=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 vGbCmjCukb1F for ; Wed, 24 Feb 2016 19:35:51 -0800 (PST) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC521B2ED3 for ; Wed, 24 Feb 2016 19:35:51 -0800 (PST) Received: from LTMC2122.kddi.com (LTMC2122.kddi.com [10.206.0.63]) by post-send.kddi.com (KDDI Mail) with ESMTP id E26AEE00F8; Thu, 25 Feb 2016 12:35:49 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2122.kddi.com with ESMTP; Thu, 25 Feb 2016 12:35:49 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id BBF9D4C005A; Thu, 25 Feb 2016 12:35:49 +0900 (JST) Received: from LTMC2151.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id B0B264C0058; Thu, 25 Feb 2016 12:35:49 +0900 (JST) Received: from LTMC2151.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u1P3Zn44032692; Thu, 25 Feb 2016 12:35:49 +0900 Received: from LTMC2151.kddi.com.mid_32662852 (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u1P3Pkm4025420; Thu, 25 Feb 2016 12:25:46 +0900 X-SA-MID: 32662852 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Thu, 25 Feb 2016 12:25:46 +0900 From: "Ogaki, Kenichi" To: "'Aijun Wang'" <13301168517@189.cn>, , References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> <004101d16e97$e0692800$a13b7800$@kddi.com> <002d01d16e9f$88e66130$9ab32390$@cn> <006701d16ec0$1063fee0$312bfca0$@kddi.com> <004301d16ec8$270d9090$7528b1b0$@cn> <008401d16ede$20cee4c0$626cae40$@kddi.com> <004201d16f6f$22023cc0$6606b640$@cn> In-Reply-To: <004201d16f6f$22023cc0$6606b640$@cn> Date: Thu, 25 Feb 2016 12:25:46 +0900 Message-ID: <015201d16f7c$3725b160$a5711420$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+JsdlYZ7cvi/Fz8JTONaqj4LvoQKs2aO/AYjUCCUDWny42AHbJwT5AVTH19oBa6ZKmwJ6yFzNnW11d6A= Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 03:35:57 -0000 Hi Aijun, If we configure the relationship between vpn-svc and sites as follows, = we should remove corresponding vpn-policy under sites to avoid the = inconsistency. In this case, when we create new sites, we must configure both sites and = vpn-svc, and this bothers our customers. But, the current model structure only have to configure sites. Then, I = prefer the current one. I don't object the sites list defined under vpn-svc as a *op-state*. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 10:52 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Based on our discussion, do you think the following proposal are = acceptable? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } =20 list sites{ leaf site-id leaf site-role leafref path "/l3vpn-svc/site-templates/site-template-id" = =20 } } list site-templates{ ...=20 } ... } -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Wednesday, February 24, 2016 4:34 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >Within the current Yang model, it is not loose coupled for the vpn and=20 >sites. Every site is associated with at least one vpn-policy entry. I wanted to mean by loose coupling that vpn and site should be = structurally at the same level. This means that a kind of graph = structure is better than a hierarchical structure. In a VPN service, it=E2=80=99s natural that a site must belong to at = least one vpn. >The reason that I prefer the "vpn-->site" structure to "site-->vpn"=20 >structure is that the majority of containers within lists "sites" are=20 >vpn-related, as you also confirmed this. >From the configuration viewpoint in the current model, the link = information between vpn and site can be configurable only in sites. = That's vpn-policy. This is reasonable to avoid the inconsistency in the case that both can = be configurable.=20 This information, which site belongs to which vpn, may be able to be = moved under vpn-svc as a list, but I don't think the necessity. It may = be useful to define the op-state under vpn-svc as discussed in issue#6. I agreed with the principle what you wrote, but I didn't carefully = discuss each container should be under vpn-svc or site. IMO, if any container is placed inappropriately, we should just move it = to the appropriate place. It's different problem from the model = structure discussion. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 2:57 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Within the current Yang model, it is not loose coupled for the vpn and = sites. Every site is associated with at least one vpn-policy entry.=20 The reason that I prefer the "vpn-->site" structure to "site-->vpn" = structure is that the majority of containers within lists "sites" are = vpn-related, as you also confirmed this. Then it is not enough in = current Yang model to correlate only the "vpn-policy" container to = different vpn id. And on the other way, we can also use the site-template to lessen the = burden of the customer configuration, as that done in current Yang = model. -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 12:59 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. > >[KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. >For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. >Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. >In that sense, I basically prefer the current model. >[Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. >There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement? If a physical customer site connects to two different vpns in this case, = the customer must input or update the information about the (physical) = site duplicately per vpn-svc. This may cause misconfiguration and bother = our customers. Another concern is the inconsistency with accounting/charging model, = when an operator charges the fee for physical access, it becomes = inconsistent with the charging model. When we does a traffic accounting = not only for logical access per vpn, but also for physical access, we = must always take care of the existence of different vpn-svc with the = same physical access in order to trigger a polling traffic counter of = the interface on PE. I understand it depends on each operator's service definition, vpn = specific or site specific, as Stephane wrote. To accommodate these different requirements, I think the loose coupled = model between the components, vpn and site, seems better. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 10:06 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Please see the reply inline. Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network = Research and Operation Support Department -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 8:11 AM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, See comments inline, please. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 18, 2016 1:12 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Stephane and Ogaki: =20 I suggested we put the "extranet-vpn-policy" under the list "vpn-svc" = directly, not in the container "vpn-policy" that is now under the list = "sites" in current model.=20 [KO]Like this? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } ... } ... } [Aijun Wang]: Yes. This can solve the initial scenario that proposed by Kenichi at the = beginning of our discussion. When the orchestrator receives the = information defined in "extranet-vpn-policy", it can allocate new = route-target for the involved VPNs and set them in the configuration = stanza of each router. =20 For the relationship of list "vpn-svc" and list "sites", I still suggest = we put the list "site" under the "vpn-svc", the reason for doing this is = as below: 1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. [KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. In that sense, I basically prefer the current model. [Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement?=20 2. The attributes of "sites", such as "maximum-routes", "security", = "service", "routing-protocols","site-netwok-accesses" etc. are all = service/site role related, that is to say, if the site role changed, all = of these attributed may be changed accordingly. [KO] I basically agree. The attributes tied to a whole vpn and globally = applied to all the sites under the vpn should be defined with the vpn = definition. 3.For container "vpn policy" that under list "sites" in current model, = there are two information defined, one is "filter" for prefix filtering, = another is "site-role". I suggest we split it, put the leaf "site-role" = under leaf "site-id" directly, and change the name of "vpn-policy" to = "site-prefix-policy".=20 =20 The final suggest structure of the L3VPN yang model will be look like = the bellow, I underline the changed positions from the current l3vpn = Yang Model =20 Container L3vpn-svc List vpn-svc Leaf vpn-id Leaf customer-name Leaf topology List extranet-vpn-policy Container cloud-access List multicast Leaf mpls List transport-contraints =20 List sites Leaf site-id Leaf site-role leaf apply-template ... ... ... ... Container managent Container site-prefix-policy Container maximum-routes Container security ... ... ... ... Site-network-access=20 =20 =20 Whether is it more reasonable?=20 =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute=20 Network Research and Operation Support Department =20 =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 18, 2016 9:08 AM To: l3sm@ietf.org Subject: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday = L3SM interim session =20 Hi Stephane and All, =20 As for issue #10 itself, the following solution can be acceptable for = us. =20 >One proposal could be to not call this VPN policy, but creating a >container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). =20 What model is in your mind? I can't see what ""extranet-vpn-policy" at = vpn" means. Like this? =20 ... 1 VPN1 VPN2 ... =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of stephane.litkowski@orange.com = =20 Sent: Monday, December 07, 2015 11:45 PM To: Ogaki, Kenichi; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi Kenichi, =20 Regarding your proposal of having a simple VPN policy in the vpn-svc = container, I do see an issue. One of the key point of the VPN policy is = to express the role of the site in the target VPN topology. If we do a vpn policy at VPN level, we cannot anymore describe site = roles in the target VPN which causes an issue. In an ideal world where all VPNs are any to any, the site role is always = the same and there is no issue, but let's think about someone trying to = use the vpn-policy (at vpn level) to connect to a Hub & Spoke VPN, how = do you deduce the roles of the sites ? =20 One proposal could be to not call this VPN policy, but creating a = container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). This means that the usage is really limited to "simple" = extranet-vpns and it does not replace nor compete with the VPN policy at = site level. =20 Could it be a good compromise ? =20 Stephane =20 =20 -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com = ] Sent: Saturday, December 05, 2015 06:23 To: LITKOWSKI Stephane SCE/OINIS; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear Stephane and All, =20 I don't say that sites *must* move under vpn-svc because I understand = stephane's use case. But we already have vpn-svc and some parameters under this are globally = applied to all the sites even in the current model. =20 It depends on operator's use case which is site-oriented or vpn-oriented = service. Our service is vpn-oriented, site has the native VPN. Then, I would just = like you to allow other global options to vpn-svc. =20 Thanks, Kenichi =20 -----Original Message----- From: stephane.litkowski@orange.com = = [mailto:stephane.litkowski@orange.com = ] Sent: Friday, December 04, 2015 8:17 PM To: Aijun Wang; 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi, =20 I'm against this proposal, as I do not want to create any dependency = between a particular VPN and a list of sites. A site can belong to multiple VPNs with any kind of topology, if we = attach the site to a single VPN, we come back to the notion of "native = VPN" we had at the beginning of the model which was hard to understand = and so was removed. =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Aijun Wang Sent: Friday, December 04, 2015 02:44 To: 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear all: =20 Can we put the list "sites" within the list "vpn-svc", and define the = general vpn policy for all sites that within the corresponding vpn = service instance? If doing so, some entries within the current list "sites" can also be = dragged out for general usual purposes, for example, "maximum-routes", = "security" etc. These parameters are often all same for every site = within one VPN service instance.=20 =20 If some sites have special requirements, we can achieve this by using = some special "site-vpn-policy" within the corresponding site definition. Is this more acceptable for customers? =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute Intelligent = Network Product Line =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Ogaki, Kenichi Sent: Friday, December 04, 2015 9:02 AM To: 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear All, =20 It was good having discussion. =20 As for issue#10, the objective and problem we discussed in the meeting = as follows. =20 The objective is to provide per-VPN extranet service which connects two = different VPNs (e.g. VPN1 and VPN2). It means that any sites in VPN1 can = access to any sites in VPN2. The problem is that the current model must update vpn-policy under all = the sites belong to these two VPNs in order to offer this service. = Especially when this model is used as a customer self-control API, it's = not good idea to require customers to update the information of all the = sites. (It's not abstracted way, a service model should provide what the = consumer wants, not how.) If a service or customer requires to control = per-site vpn-policy, that of current model should be used without = setting per-VPN vpn-polity. It depends on each operator's service. Stephane proposed to use apply-template, but it still cannot solve the = problem. When each VPN already has a large number of sites and want to = connect each other for the first time, both VPNs must update these sites = to apply apply-template on the current model. =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Qin Wu Sent: Friday, December 04, 2015 12:42 AM To: l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: [L3sm] L3SM interim meeting minutes on Thursday L3SM interim = session =20 Hi all: =20 =20 Below is the initial version of draft minutes for Thursday L3SM WG = interim session. =20 Thanks Dan to help take minutes. =20 Folks, please let us know if you have any correction. =20 =20 -Qin =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =20 L3SM Working Group Virtual Interim Meeting=20 =20 Thursday December 5th, 2015. 8am East Coast Time (New York) =20 =20 BLUE SHEET =20 =20 Name | Affiliation =20 ------------------------+----------------------------------------------- ------------------------+- =20 Adrian Farrel | Old Dog Consulting =20 Qin Wu | Huawei Technologies =20 Stephane Litkowski | Orange =20 Luis Tomotaki | Verizon =20 Daniel King | Old Dog Consulting =20 Susan Hares | Huawei Technologies =20 Scott Mansfield | Ericsson =20 Gu Rong | China Mobile=20 =20 Kenichi Ogaki | KDDI =20 Aijun Wang | China Telecom =20 Victor Santos | Ericsson =20 Ignas Bagdonas |=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 MINUTES =20 =20 * Meting logiistics = https://mailarchive.ietf.org/arch/msg/l3sm/SJub1aHVQGOQW6rWhthX0fB8Ac8 = = =20 =20 * Meeting materials = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/proceedings.html= = =20 =20 * Etherpad for minutes (this page) = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03 = =20 =20 * Jabber using l3sm@jabber.ietf.org =20 =20 * Blue sheet = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03-bluesheet = = =20 =20 =20 Agendaa =20 - Administrivia (Note Well, etc). a =20 - Introduction =20 - Open Issues for YANG Data Model for L3VPNservice delivery = (draft-ietf-l3sm-l3vpn-servicemodel) =20 o Open Issues discussion and resolution=E2=80=93 = http://trac.tools.ietf.org/wg/l3sm/trac/report/1 = =20 =20 =20 For a full list of issues and resolution proposals please see: = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/slides/slides-in= terim-2015-l3sm-1-2.pdf = =20 =20 =20 Issue#1: When customer-nat-address is used =20 Resolution #1: Leaf used when NAT is required to access cloud VPN and = customer wants to use its ownIP address. If provider provides the public = IP,no need to use the leaf =20 Status #1: Closed Pending I-D text review. =20 =20 Discussion on #1:=20 =20 =20 Aijun asks for more description in the YANG model itself =20 Stephane shows current model =20 Agreed OK =20 =20 Issue#2 : Identify l3vpn svc using id or name or both =20 Resolution #2: ID is a string, as per other properties in the model =20 Status #2: Closed =20 Discussion on #2:=20 =20 =20 Agreed OK =20 =20 Issue#3: M to N availability support =20 Resolution #3: Modeling sites using a list with a priority, so include = access list with a priority. =20 Status #3: =20 Discussion on #3:=20 =20 =20 Qin was asking that M to N availability is supported with access and = priority number.=20 =20 Stephane stated this is suppoted. This new proposal also supports = multiple sites, as a list. =20 Qin also asked if Group I-D was no longer needed, which it is not. Also = good solution supported by other operators. =20 Stephane asked if four priorities was enough, or if more were needed.=20 =20 =20 Re: Containers/Properties for Network Access Configuration - = Conclusions? =20 =20 o Location - Different site I-D? =20 o QoS Policy - Per network access link, or site information? Would QoS = (cost) be different per accesslink or site? Example of Primary and = Backup links given.=20 =20 o Bandwidth - Moved to access link group=20 =20 o Maximum Routes -=20 =20 Security, routing, and services are duplicated with inheritance =20 =20 =20 Issue#4: site-service-cloud access as grouping =20 Resolution #4 Already resilved as a separate grouping =20 Status #4: Closed =20 Discussion on #4:=20 =20 =20 Issue#5: Multicast support as raised by Eric Rosen =20 Resolution #5: : New "provider managed" property, and in Site Properties = "property-type" added =20 Status #5: Solution proposed.=20 =20 Discussion on #5:=20 =20 =20 Stephane will proviode new property proposals will be provided to Eric = for review.=20 =20 =20 Issue#6: Inventory operational state =20 Resolution #6: Include a new container for inventory state, or an RPC = call (sitting above the service orchestrator) to retrieve inventory = state.=20 =20 Status #6: Need to propose to the WG and agree solution. =20 Discussion on #6:=20 =20 =20 Luis asked would this info be collected from provision state? Stephane = suggested this would not be availible.=20 =20 Adrian observed that the code used to convert the model into a service = request may not utilise this inventory information capability. Sue = mentioned that others have mentioned by a vendor that it would be useful = to have the ability to configure inventory state. This should be = clarified by the operators.=20 =20 =20 Stephane to take proposals to list and ask anyone who is interested in = having the feature to suggest text. =20 =20 =20 Issue#7: Generic VAS - do we need to create a generic VAS container as = VAS are popular in L3VPNs? =20 Resolution #7: Separate from L3SM =20 Status #7: Closed =20 Discussion on #7:=20 =20 =20 Gu Rong highlighted Generic VAS model which was presented at IETF 94.=20 =20 =20 Issue#8: Who keeps site locationinformation? =20 Resolution #8: Text has been fixed =20 Status #8: Closed =20 Discussion on #8:=20 =20 =20 =20 Issue#9: Do we need to model transport constraints, such as: jitter, = disjoint, path diversity? =20 Resolution #9: Propose a "transport-constraint" group with = "constraint-type", "constraint-value" and "constraint-list" (composed of = type and values) =20 Status #9: Authors to propose the resolution in the I-D and provide to = the WG =20 Discussion on #9: =20 =20 =20 =20 Luis mentioned that they have multicast transport (multiple sites) and = bi-directional traffic applications (financial) that will require = transport constraints =20 =20 Duplicate transport constraints for unicast and multicast to give = options for separate configuration. =20 Keep single list entries for each src/dst pair even in the multicast = variant. =20 =20 DO we need to support multiple constraints or just have a single = composite (of multiple constraints), have the ability to specify a = constraint-list? =20 Aijun prfers list of constraints and meeting agrees this is OK =20 =20 What constraints to offer? =20 Latency =20 Path diversty =20 Site diversty =20 Jitter =20 Class of service was proposed but rejected =20 =20 Luis highlighted they have a current implementation that uses the = similar proposal. Luis also mentioned that site diversity might also be = required, would this be achievable =20 =20 =20 Issue#10: VPN "merging" =20 Resolution #10: =20 =20 Status #10: =20 Discussion on #10: =20 =20 =20 VPN is a per site property.=20 =20 - A site can belong tomultiple VPNs =20 - How to handle merging of two VPNs? =20 - Is this an issue the service model has to deal with? =20 =20 If VPN merging is required to be seamless, then this would be device = specific and not service model related. =20 =20 =20 "Merging" is a confusing term. The objective is NOT to merge VPN1 and = VPN2. =20 The objective is to provide an extranet so that some sites in VPN1 can = connect to some sites in VPN2 for some traffic. =20 This can be solved using a per-site property. =20 =20 Action: Need to update this issue to make it clear what function was = being discussed, also Stephane will send options to the working group- = list.=20 =20 We are specifically looking for people who offer extranet connection = between sites from different VPNs =20 =20 =3D=3D Other Issues =3D=3D =20 =20 =20 Modeling Customer Specific Info =20 - Create appropiate containers for Provider Edge and Customer Site = routers =20 - The current model contains routing parametres that refer to CE and PE = relationships =20 - General agreement is routing info should be split and current proposal = will be sent to the list for Kenichi, and working groups, review.=20 =20 =20 =3D=3D Conclusions =3D=3D =20 =20 - A number of resolutions have been agreed and will be updated in the = I-D =20 - Chairs would like to see revised I-D based on the agreed points =20 - Plan to have another interim call at the end of January (2016) =20 - Chairs to add new tracker items, including security for future = discussion.=20 =20 =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 _______________________________________________ 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 _______________________________________________ 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 From nobody Wed Feb 24 19:48:17 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB9D1A87BA for ; Wed, 24 Feb 2016 19:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.048 X-Spam-Level: *** X-Spam-Status: No, score=3.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=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 C2AKG6LnWNIj for ; Wed, 24 Feb 2016 19:48:11 -0800 (PST) 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 F07231A8740 for ; Wed, 24 Feb 2016 19:48:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEY91746; Thu, 25 Feb 2016 03:48:06 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 03:48:01 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 11:47:56 +0800 From: Qin Wu To: Aijun Wang <13301168517@189.cn>, "'Ogaki, Kenichi'" , "stephane.litkowski@orange.com" , "l3sm@ietf.org" Thread-Topic: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session Thread-Index: AdFUzU8XUm4agADpQBu6GQYzpCj8XwVLtpZwARYqJIAAAejoAAAIIwmAAAIEnwAABX+QAAAkPvQAABRtUWA= Date: Thu, 25 Feb 2016 03:47:56 +0000 Message-ID: References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> <004101d16e97$e0692800$a13b7800$@kddi.com> <002d01d16e9f$88e66130$9ab32390$@cn> <006701d16ec0$1063fee0$312bfca0$@kddi.com> <004301d16ec8$270d9090$7528b1b0$@cn> <008401d16ede$20cee4c0$626cae40$@kddi.com> <004201d16f6f$22023cc0$6606b640$@cn> In-Reply-To: <004201d16f6f$22023cc0$6606b640$@cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.208] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56CE7977.0067, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f9d4b28207e13f101c0388bd3ec1fd45 Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 03:48:16 -0000 QWlqdW46DQpJdCBsb29rcyBsaWtlIHlvdSBwcm9wb3NlIHRvIHJlbG9jYXRlIHNvbWUgcGFyYW1l dGVycyBpbiB0aGUgbW9kZWwgc3RydWN0dXJlLg0KQnV0IHdpdGggeW91ciBwcm9wb3NhbCwgaXQg aXMgaGFyZCB0byBkZXNjcmliZSBvbmUgc2l0ZSBwbGF5aW5nIGRpZmZlcmVudCByb2xlIGluIGRp ZmZlcmVudCBWUE4gd2hlbiBvbmUgc2l0ZSBiZWxvbmdzIHRvIG11bHRpcGxlIFZQTnMuDQpXaXRo IFZQTi1wb2xpY3kgdW5kZXIgc2l0ZSBwcm9wb3NlZCBpbiB0aGUgY3VycmVudCBtb2RlbCwgeW91 IGNhbiBlYXNpbHkgZGVzY3JpYmUgb25lIHNpdGUgd2l0aCBkaWZmZXJlbnQgcm9sZSBpbiBlYWNo IFZQTiBhcyBmb2xsb3dzOg0KIg0KICAgIGNvbnRhaW5lciBsM3Zwbi1zdmMgew0KICAgICAgICBs aXN0IHZwbi1zdmMgew0KICAgICAgICAgICAga2V5IHZwbi1pZDsNCg0KICAgICAgICAgICAgbGVh ZiB2cG4taWQgew0KICAgICAgICAgICAgICAgIOKApg0KICAgICAgICAgICAgfQ0KICAgICAgICAg ICAgLi4uDQogICAgICAgIA0KICAgICAgICAgICAgbGlzdCBzaXRlc3sNCiAgICAgICAgICAgICAg bGVhZiBzaXRlLWlkDQogICAgICAgICAgY29udGFpbmVyIHZwbi1wb2xpY3kgew0KICAgICAgICAg ICAgbGlzdCBlbnRyaWVzIHsNCiAgICAgICAgICAgICAgICBrZXkgaWQ7DQogICAgICAgICAgICAg ICAgbGVhZiBpZCB7DQogICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHN2Yy1pZDsNCiAgICAg ICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAg IlVuaXF1ZSBpZGVudGlmaWVyIGZvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgcG9s aWN5IGVudHJ5LiI7DQogICAgICAgICAgICAgICAgfQ0KY29udGFpbmVyIHZwbiB7DQogICAgICAg ICAgICAgICAgICAgIGxlYWYgdnBuIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgbGVh ZnJlZiB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgcGF0aCAiL2wzdnBuLXN2Yy92cG4t c3ZjL3Zwbi1pZCI7DQogICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAg ICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsNCiAgICAgICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0 aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgIlJlZmVyZW5jZSB0byBhbiBJUFZQTi4iOw0K ICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgIGxlYWYgc2l0ZS1yb2xl IHsNCiAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgaWRlbnRpdHlyZWYgew0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGJhc2Ugc2l0ZS1yb2xlOw0KICAgICAgICAgICAgICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAgICAgICAg ICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICJSb2xl IG9mIHRoZSBzaXRlIGluIHRoZSBJUFZQTi4iOw0KICAgICAgICAgICAgICAgICAgICB9DQogICAg ICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAgICAgICAiTGlzdCBv ZiBWUE5zIHRoZSBMQU4gaXMgYXNzb2NpYXRlZCB0by4iOw0KICAgICAgICAgICAgICAgIH0NCg0K ICAgICAgICAgICAgfQ0KICAgICAgICB9DQoiDQotUWluDQotLS0tLemCruS7tuWOn+S7ti0tLS0t DQrlj5Hku7bkuro6IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBB aWp1biBXYW5nDQrlj5HpgIHml7bpl7Q6IDIwMTblubQy5pyIMjXml6UgOTo1Mg0K5pS25Lu25Lq6 OiAnT2dha2ksIEtlbmljaGknOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBp ZXRmLm9yZw0K5Li76aKYOiBSZTogW0wzc21dIElzc3VlICMxMCBSRTogTDNTTSBpbnRlcmltIG1l ZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGludGVyaW0gc2Vzc2lvbg0KDQpIaSwgT2dh a2k6DQoNCkJhc2VkIG9uIG91ciBkaXNjdXNzaW9uLCBkbyB5b3UgdGhpbmsgdGhlIGZvbGxvd2lu ZyBwcm9wb3NhbCBhcmUgYWNjZXB0YWJsZT8NCg0KICAgIGNvbnRhaW5lciBsM3Zwbi1zdmMgew0K ICAgICAgICBsaXN0IHZwbi1zdmMgew0KICAgICAgICAgICAga2V5IHZwbi1pZDsNCg0KICAgICAg ICAgICAgbGVhZiB2cG4taWQgew0KICAgICAgICAgICAgICAgIOKApg0KICAgICAgICAgICAgfQ0K ICAgICAgICAgICAgLi4uDQogICAgICAgICAgICBsaXN0IGV4dHJhbmV0LXZwbi1wb2xpY3kgew0K ICAgICAgICAgICAgICAgIGtleSB2cG4taWQ7DQogICAgICAgICAgICAgICAgbGVhZiB2cG4taWQg ew0KICAgICAgICAgICAgICAgICAgICB0eXBlIHN2Yy1pZDsNCiAgICAgICAgICAgICAgICB9DQog ICAgICAgICAgICB9DQogICAgICAgIA0KICAgICAgICAgICAgbGlzdCBzaXRlc3sNCiAgICAgICAg ICAgICAgbGVhZiBzaXRlLWlkDQogICAgICAgICAgICAgIGxlYWYgc2l0ZS1yb2xlDQogICAgICAg ICAgICAgIGxlYWZyZWYgcGF0aCAiL2wzdnBuLXN2Yy9zaXRlLXRlbXBsYXRlcy9zaXRlLXRlbXBs YXRlLWlkIiAgICANCiAgICAgICAgICAgIH0NCiAgICAgICAgfQ0KDQogICAgICAgIGxpc3Qgc2l0 ZS10ZW1wbGF0ZXN7DQogICAgICAgIC4uLiANCiAgICAgICAgfQ0KICAgICAgICAuLi4NCiAgICB9 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2dha2ksIEtlbmljaGkNClNlbnQ6IFdlZG5l c2RheSwgRmVicnVhcnkgMjQsIDIwMTYgNDozNCBQTQ0KVG86ICdBaWp1biBXYW5nJzsgc3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTDNz bV0gSXNzdWUgIzEwIFJFOiBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9uIFRodXJzZGF5 IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCkhpIEFpanVuLA0KDQo+V2l0aGluIHRoZSBjdXJyZW50 IFlhbmcgbW9kZWwsIGl0IGlzIG5vdCBsb29zZSBjb3VwbGVkIGZvciB0aGUgdnBuIGFuZCANCj5z aXRlcy4gRXZlcnkgc2l0ZSBpcyBhc3NvY2lhdGVkIHdpdGggYXQgbGVhc3Qgb25lIHZwbi1wb2xp Y3kgZW50cnkuDQoNCkkgd2FudGVkIHRvIG1lYW4gYnkgbG9vc2UgY291cGxpbmcgdGhhdCB2cG4g YW5kIHNpdGUgc2hvdWxkIGJlIHN0cnVjdHVyYWxseSBhdCB0aGUgc2FtZSBsZXZlbC4gVGhpcyBt ZWFucyB0aGF0IGEga2luZCBvZiBncmFwaCBzdHJ1Y3R1cmUgaXMgYmV0dGVyIHRoYW4gYSBoaWVy YXJjaGljYWwgc3RydWN0dXJlLg0KSW4gYSBWUE4gc2VydmljZSwgaXTigJlzIG5hdHVyYWwgdGhh dCBhIHNpdGUgbXVzdCBiZWxvbmcgdG8gYXQgbGVhc3Qgb25lIHZwbi4NCg0KDQo+VGhlIHJlYXNv biB0aGF0IEkgcHJlZmVyIHRoZSAidnBuLS0+c2l0ZSIgc3RydWN0dXJlIHRvICJzaXRlLS0+dnBu IiANCj5zdHJ1Y3R1cmUgaXMgdGhhdCB0aGUgbWFqb3JpdHkgb2YgY29udGFpbmVycyB3aXRoaW4g bGlzdHMgInNpdGVzIiBhcmUgDQo+dnBuLXJlbGF0ZWQsIGFzIHlvdSBhbHNvIGNvbmZpcm1lZCB0 aGlzLg0KDQo+RnJvbSB0aGUgY29uZmlndXJhdGlvbiB2aWV3cG9pbnQgaW4gdGhlIGN1cnJlbnQg bW9kZWwsIHRoZSBsaW5rIGluZm9ybWF0aW9uIGJldHdlZW4gdnBuIGFuZCBzaXRlIGNhbiBiZSBj b25maWd1cmFibGUgb25seSBpbiBzaXRlcy4gVGhhdCdzIHZwbi1wb2xpY3kuDQpUaGlzIGlzIHJl YXNvbmFibGUgdG8gYXZvaWQgdGhlIGluY29uc2lzdGVuY3kgaW4gdGhlIGNhc2UgdGhhdCBib3Ro IGNhbiBiZSBjb25maWd1cmFibGUuIA0KVGhpcyBpbmZvcm1hdGlvbiwgd2hpY2ggc2l0ZSBiZWxv bmdzIHRvIHdoaWNoIHZwbiwgbWF5IGJlIGFibGUgdG8gYmUgbW92ZWQgdW5kZXIgdnBuLXN2YyBh cyBhIGxpc3QsIGJ1dCBJIGRvbid0IHRoaW5rIHRoZSBuZWNlc3NpdHkuIEl0IG1heSBiZSB1c2Vm dWwgdG8gZGVmaW5lIHRoZSBvcC1zdGF0ZSB1bmRlciB2cG4tc3ZjIGFzIGRpc2N1c3NlZCBpbiBp c3N1ZSM2Lg0KDQpJIGFncmVlZCB3aXRoIHRoZSBwcmluY2lwbGUgd2hhdCB5b3Ugd3JvdGUsIGJ1 dCBJIGRpZG4ndCBjYXJlZnVsbHkgZGlzY3VzcyBlYWNoIGNvbnRhaW5lciBzaG91bGQgYmUgdW5k ZXIgdnBuLXN2YyBvciBzaXRlLg0KSU1PLCBpZiBhbnkgY29udGFpbmVyIGlzIHBsYWNlZCBpbmFw cHJvcHJpYXRlbHksIHdlIHNob3VsZCBqdXN0IG1vdmUgaXQgdG8gdGhlIGFwcHJvcHJpYXRlIHBs YWNlLiBJdCdzIGRpZmZlcmVudCBwcm9ibGVtIGZyb20gdGhlIG1vZGVsIHN0cnVjdHVyZSBkaXNj dXNzaW9uLg0KDQoNClRoYW5rcywNCktlbmljaGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBBaWp1biBXYW5nDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDI6NTcgUE0N ClRvOiAnT2dha2ksIEtlbmljaGknOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNz bUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtMM3NtXSBJc3N1ZSAjMTAgUkU6IEwzU00gaW50ZXJp bSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KSGks IE9nYWtpOg0KDQpXaXRoaW4gdGhlIGN1cnJlbnQgWWFuZyBtb2RlbCwgaXQgaXMgbm90IGxvb3Nl IGNvdXBsZWQgZm9yIHRoZSB2cG4gYW5kIHNpdGVzLiBFdmVyeSBzaXRlIGlzIGFzc29jaWF0ZWQg d2l0aCBhdCBsZWFzdCBvbmUgdnBuLXBvbGljeSBlbnRyeS4gDQpUaGUgcmVhc29uIHRoYXQgSSBw cmVmZXIgdGhlICJ2cG4tLT5zaXRlIiBzdHJ1Y3R1cmUgdG8gInNpdGUtLT52cG4iIHN0cnVjdHVy ZSBpcyB0aGF0IHRoZSBtYWpvcml0eSBvZiBjb250YWluZXJzIHdpdGhpbiBsaXN0cyAic2l0ZXMi IGFyZSB2cG4tcmVsYXRlZCwgYXMgeW91IGFsc28gY29uZmlybWVkIHRoaXMuIFRoZW4gaXQgaXMg bm90IGVub3VnaCBpbiBjdXJyZW50IFlhbmcgbW9kZWwgdG8gY29ycmVsYXRlIG9ubHkgdGhlICJ2 cG4tcG9saWN5IiBjb250YWluZXIgdG8gZGlmZmVyZW50IHZwbiBpZC4NCkFuZCBvbiB0aGUgb3Ro ZXIgd2F5LCB3ZSBjYW4gYWxzbyB1c2UgdGhlIHNpdGUtdGVtcGxhdGUgdG8gbGVzc2VuIHRoZSBi dXJkZW4gb2YgdGhlIGN1c3RvbWVyIGNvbmZpZ3VyYXRpb24sIGFzIHRoYXQgZG9uZSBpbiBjdXJy ZW50IFlhbmcgbW9kZWwuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPZ2Fr aSwgS2VuaWNoaSBbbWFpbHRvOmtlLW9vZ2FraUBrZGRpLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwg RmVicnVhcnkgMjQsIDIwMTYgMTI6NTkgUE0NClRvOiAnQWlqdW4gV2FuZyc7IHN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0wzc21dIElz c3VlICMxMCBSRTogTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NN IGludGVyaW0gc2Vzc2lvbg0KDQpIaSBBaWp1biwNCg0KPjEuIHRoZSBzZXJ2aWNlIG1vZGVsIG11 c3QgYmUgc2VydmljZSBvcmllbnRlZC4gSWYgb25lIHNpdGUgYmVsb25ncyB0byBzZXZlcmFsIHZw bnMsIHdlIHNob3VsZCBhY2hpZXZlIHRoZSBnb2FsIGJ5IGRlZmluaW5nIHNldmVyYWwgc2Vydmlj ZSBpbnN0YW5jZXMuDQo+DQo+W0tPXSBJIGNhbid0IGFncmVlIHRoaXMuIFRoZSBjYXNlIHRoYXQg YSBzaXRlIGJlbG9uZ3MgdG8gbXVsdGlwbGUgdnBucyBpcyBhbHNvIGEgdmVyeSBjb21tb24gc2Vy dmljZSB1c2UgY2FzZSwgdGhlbiB0aGUgc2VydmljZSBtb2RlbCBtdXN0IGRlc2lnbiB0aGlzIGFw cHJvcHJpYXRlbHkuDQo+Rm9yIGVhc3kgdXNlIG9mIGEgc2VydmljZSBtb2RlbCBhbmQgdG8gYXZv aWQgdGhlIG1pc2NvbmZpZ3VyYXRpb24gYW5kIGluY29uc2lzdGVuY3ksIHdlIGhhdmUgdG8gZXhj bHVkZSBkdXBsaWNhdGUgY29uZmlndXJhdGlvbiBmb3IgdGhlIHNhbWUgaW5mb3JtYXRpb24sIGRh dGEgbm9kZSBpbnN0YW5jZSwgYXMgbXVjaCBhcyBwb3NzaWJsZS4gPlRoZW4sIEkgcHJvcG9zZWQg dG8gcmVtb3ZlIHJlcGV0aXRpdmUgZGVmaW5pdGlvbnMgb2YgYSB2cG4gd2hpY2ggY2FuIGJlIGlt cGxpY2l0bHkgdW5pcXVlbHkgaWRlbnRpZmllZCBpbiBhIHNhbWUgdHJhbnNhY3Rpb24uIEJ1dCwg dGhhdCBldmVudHVhbGx5IGNhbWUgbm90IHRvIG1ha2Ugc2Vuc2UgZm9yIHJlc3Rjb25mLg0KPklu IHRoYXQgc2Vuc2UsIEkgYmFzaWNhbGx5IHByZWZlciB0aGUgY3VycmVudCBtb2RlbC4NCj5bQWlq dW4gV2FuZ106IGZvciBzaXRlcyB0aGF0IGJlbG9uZyB0byBzZXZlcmFsIHZwbnMsIGJlY2F1c2Ug d2UgZGVmaW5lICJ2cG4tc3ZjIiBhcyBsaXN0LCB0aGVuIGl0IGNhbiBpbmNsdWRlIGRpZmZlcmVu dCBpdGVtcywgZWFjaCB2cG4tc3ZjIGl0ZW0gY2FuIGRlZmluZSBpdHMgb3duIHNpdGVzIGNvdmVy YWdlIGluZm9ybWF0aW9uLiA+VGhlcmUgaXMgYWxzbyBubyBkdXBsaWNhdGUgY29uZmlndXJhdGlv biBmb3IgdGhpcyBzb2x1dGlvbi4gV2hhdCdzIHRoZSBwcm9ibGVtIHRoZW4gZm9yIHRoaXMgYXJy YW5nZW1lbnQ/DQoNCklmIGEgcGh5c2ljYWwgY3VzdG9tZXIgc2l0ZSBjb25uZWN0cyB0byB0d28g ZGlmZmVyZW50IHZwbnMgaW4gdGhpcyBjYXNlLCB0aGUgY3VzdG9tZXIgbXVzdCBpbnB1dCBvciB1 cGRhdGUgdGhlIGluZm9ybWF0aW9uIGFib3V0IHRoZSAocGh5c2ljYWwpIHNpdGUgZHVwbGljYXRl bHkgcGVyIHZwbi1zdmMuIFRoaXMgbWF5IGNhdXNlIG1pc2NvbmZpZ3VyYXRpb24gYW5kIGJvdGhl ciBvdXIgY3VzdG9tZXJzLg0KQW5vdGhlciBjb25jZXJuIGlzIHRoZSBpbmNvbnNpc3RlbmN5IHdp dGggYWNjb3VudGluZy9jaGFyZ2luZyBtb2RlbCwgd2hlbiBhbiBvcGVyYXRvciBjaGFyZ2VzIHRo ZSBmZWUgZm9yIHBoeXNpY2FsIGFjY2VzcywgaXQgYmVjb21lcyBpbmNvbnNpc3RlbnQgd2l0aCB0 aGUgY2hhcmdpbmcgbW9kZWwuIFdoZW4gd2UgZG9lcyBhIHRyYWZmaWMgYWNjb3VudGluZyBub3Qg b25seSBmb3IgbG9naWNhbCBhY2Nlc3MgcGVyIHZwbiwgYnV0IGFsc28gZm9yIHBoeXNpY2FsIGFj Y2Vzcywgd2UgbXVzdCBhbHdheXMgdGFrZSBjYXJlIG9mIHRoZSBleGlzdGVuY2Ugb2YgZGlmZmVy ZW50IHZwbi1zdmMgd2l0aCB0aGUgc2FtZSBwaHlzaWNhbCBhY2Nlc3MgaW4gb3JkZXIgdG8gdHJp Z2dlciBhIHBvbGxpbmcgdHJhZmZpYyBjb3VudGVyIG9mIHRoZSBpbnRlcmZhY2Ugb24gUEUuDQoN CkkgdW5kZXJzdGFuZCBpdCBkZXBlbmRzIG9uIGVhY2ggb3BlcmF0b3IncyBzZXJ2aWNlIGRlZmlu aXRpb24sIHZwbiBzcGVjaWZpYyBvciBzaXRlIHNwZWNpZmljLCBhcyBTdGVwaGFuZSB3cm90ZS4N Cg0KVG8gYWNjb21tb2RhdGUgdGhlc2UgZGlmZmVyZW50IHJlcXVpcmVtZW50cywgSSB0aGluayB0 aGUgbG9vc2UgY291cGxlZCBtb2RlbCBiZXR3ZWVuIHRoZSBjb21wb25lbnRzLCB2cG4gYW5kIHNp dGUsIHNlZW1zIGJldHRlci4NCg0KVGhhbmtzLA0KS2VuaWNoaQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFpanVuIFdhbmcNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYg MTA6MDYgQU0NClRvOiAnT2dha2ksIEtlbmljaGknOyBzdGVwaGFuZS5saXRrb3dza2lAb3Jhbmdl LmNvbTsgbDNzbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtMM3NtXSBJc3N1ZSAjMTAgUkU6IEwz U00gaW50ZXJpbSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Np b24NCg0KSGksIE9nYWtpOg0KDQpQbGVhc2Ugc2VlIHRoZSByZXBseSBpbmxpbmUuDQoNCg0KQmVz dCBSZWdhcmRzLg0KDQpBaWp1biBXYW5nDQoNCkNoaW5hIFRlbGVjb20gQ29ycG9yYXRpb24gTGlt aXRlZCBCZWlqaW5nIFJlc2VhcmNoIEluc3RpdHV0ZSBOZXR3b3JrIFJlc2VhcmNoIGFuZCBPcGVy YXRpb24gU3VwcG9ydCBEZXBhcnRtZW50DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBPZ2FraSwgS2VuaWNoaSBbbWFpbHRvOmtlLW9vZ2FraUBrZGRpLmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgODoxMSBBTQ0KVG86ICdBaWp1biBXYW5nJzsgc3Rl cGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBb TDNzbV0gSXNzdWUgIzEwIFJFOiBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9uIFRodXJz ZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCkhpIEFpanVuLA0KDQpTZWUgY29tbWVudHMgaW5s aW5lLCBwbGVhc2UuDQoNClRoYW5rcywNCktlbmljaGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBaWp1biBXYW5nDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTgsIDIwMTYgMToxMiBQ TQ0KVG86ICdPZ2FraSwgS2VuaWNoaSc7IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBs M3NtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0wzc21dIElzc3VlICMxMCBSRTogTDNTTSBpbnRl cmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGludGVyaW0gc2Vzc2lvbg0KDQpI aSwgU3RlcGhhbmUgYW5kIE9nYWtpOg0KDQogDQoNCkkgc3VnZ2VzdGVkIHdlIHB1dCB0aGUgImV4 dHJhbmV0LXZwbi1wb2xpY3kiIHVuZGVyIHRoZSBsaXN0ICJ2cG4tc3ZjIiBkaXJlY3RseSwgbm90 IGluIHRoZSBjb250YWluZXIgInZwbi1wb2xpY3kiIHRoYXQgaXMgbm93IHVuZGVyIHRoZSBsaXN0 ICJzaXRlcyIgaW4gY3VycmVudCBtb2RlbC4gDQoNCltLT11MaWtlIHRoaXM/DQoNCiAgICBjb250 YWluZXIgbDN2cG4tc3ZjIHsNCiAgICAgICAgbGlzdCB2cG4tc3ZjIHsNCiAgICAgICAgICAgIGtl eSB2cG4taWQ7DQoNCiAgICAgICAgICAgIGxlYWYgdnBuLWlkIHsNCiAgICAgICAgICAgICAgICDi gKYNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIC4uLg0KICAgICAgICAgICAgbGlzdCBleHRy YW5ldC12cG4tcG9saWN5IHsNCiAgICAgICAgICAgICAgICBrZXkgdnBuLWlkOw0KICAgICAgICAg ICAgICAgIGxlYWYgdnBuLWlkIHsNCiAgICAgICAgICAgICAgICAgICAgdHlwZSBzdmMtaWQ7DQog ICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgLi4uDQogICAgICAg IH0NCiAgICAgICAgLi4uDQogICAgfQ0KW0FpanVuIFdhbmddOiBZZXMuDQoNClRoaXMgY2FuIHNv bHZlIHRoZSBpbml0aWFsIHNjZW5hcmlvIHRoYXQgcHJvcG9zZWQgYnkgS2VuaWNoaSBhdCB0aGUg YmVnaW5uaW5nIG9mIG91ciBkaXNjdXNzaW9uLiBXaGVuIHRoZSBvcmNoZXN0cmF0b3IgcmVjZWl2 ZXMgdGhlIGluZm9ybWF0aW9uIGRlZmluZWQgaW4gImV4dHJhbmV0LXZwbi1wb2xpY3kiLCBpdCBj YW4gYWxsb2NhdGUgbmV3IHJvdXRlLXRhcmdldCBmb3IgdGhlIGludm9sdmVkIFZQTnMgYW5kIHNl dCB0aGVtIGluIHRoZSBjb25maWd1cmF0aW9uIHN0YW56YSBvZiBlYWNoIHJvdXRlci4NCg0KIA0K DQpGb3IgdGhlIHJlbGF0aW9uc2hpcCBvZiBsaXN0ICJ2cG4tc3ZjIiBhbmQgbGlzdCAic2l0ZXMi LCBJIHN0aWxsIHN1Z2dlc3Qgd2UgcHV0IHRoZSBsaXN0ICJzaXRlIiB1bmRlciB0aGUgInZwbi1z dmMiLCB0aGUgcmVhc29uIGZvciBkb2luZyB0aGlzIGlzIGFzIGJlbG93Og0KDQoxLiB0aGUgc2Vy dmljZSBtb2RlbCBtdXN0IGJlIHNlcnZpY2Ugb3JpZW50ZWQuIElmIG9uZSBzaXRlIGJlbG9uZ3Mg dG8gc2V2ZXJhbCB2cG5zLCB3ZSBzaG91bGQgYWNoaWV2ZSB0aGUgZ29hbCBieSBkZWZpbmluZyBz ZXZlcmFsIHNlcnZpY2UgaW5zdGFuY2VzLg0KDQpbS09dIEkgY2FuJ3QgYWdyZWUgdGhpcy4gVGhl IGNhc2UgdGhhdCBhIHNpdGUgYmVsb25ncyB0byBtdWx0aXBsZSB2cG5zIGlzIGFsc28gYSB2ZXJ5 IGNvbW1vbiBzZXJ2aWNlIHVzZSBjYXNlLCB0aGVuIHRoZSBzZXJ2aWNlIG1vZGVsIG11c3QgZGVz aWduIHRoaXMgYXBwcm9wcmlhdGVseS4NCkZvciBlYXN5IHVzZSBvZiBhIHNlcnZpY2UgbW9kZWwg YW5kIHRvIGF2b2lkIHRoZSBtaXNjb25maWd1cmF0aW9uIGFuZCBpbmNvbnNpc3RlbmN5LCB3ZSBo YXZlIHRvIGV4Y2x1ZGUgZHVwbGljYXRlIGNvbmZpZ3VyYXRpb24gZm9yIHRoZSBzYW1lIGluZm9y bWF0aW9uLCBkYXRhIG5vZGUgaW5zdGFuY2UsIGFzIG11Y2ggYXMgcG9zc2libGUuIFRoZW4sIEkg cHJvcG9zZWQgdG8gcmVtb3ZlIHJlcGV0aXRpdmUgZGVmaW5pdGlvbnMgb2YgYSB2cG4gd2hpY2gg Y2FuIGJlIGltcGxpY2l0bHkgdW5pcXVlbHkgaWRlbnRpZmllZCBpbiBhIHNhbWUgdHJhbnNhY3Rp b24uIEJ1dCwgdGhhdCBldmVudHVhbGx5IGNhbWUgbm90IHRvIG1ha2Ugc2Vuc2UgZm9yIHJlc3Rj b25mLg0KSW4gdGhhdCBzZW5zZSwgSSBiYXNpY2FsbHkgcHJlZmVyIHRoZSBjdXJyZW50IG1vZGVs Lg0KW0FpanVuIFdhbmddOiBmb3Igc2l0ZXMgdGhhdCBiZWxvbmcgdG8gc2V2ZXJhbCB2cG5zLCBi ZWNhdXNlIHdlIGRlZmluZSAidnBuLXN2YyIgYXMgbGlzdCwgdGhlbiBpdCBjYW4gaW5jbHVkZSBk aWZmZXJlbnQgaXRlbXMsIGVhY2ggdnBuLXN2YyBpdGVtIGNhbiBkZWZpbmUgaXRzIG93biBzaXRl cyBjb3ZlcmFnZSBpbmZvcm1hdGlvbi4gVGhlcmUgaXMgYWxzbyBubyBkdXBsaWNhdGUgY29uZmln dXJhdGlvbiBmb3IgdGhpcyBzb2x1dGlvbi4gV2hhdCdzIHRoZSBwcm9ibGVtIHRoZW4gZm9yIHRo aXMgYXJyYW5nZW1lbnQ/IA0KDQoNCjIuIFRoZSBhdHRyaWJ1dGVzIG9mICJzaXRlcyIsIHN1Y2gg YXMgIm1heGltdW0tcm91dGVzIiwgInNlY3VyaXR5IiwgInNlcnZpY2UiLCAicm91dGluZy1wcm90 b2NvbHMiLCJzaXRlLW5ldHdvay1hY2Nlc3NlcyIgZXRjLiBhcmUgYWxsIHNlcnZpY2Uvc2l0ZSBy b2xlIHJlbGF0ZWQsIHRoYXQgaXMgdG8gc2F5LCBpZiB0aGUgc2l0ZSByb2xlIGNoYW5nZWQsIGFs bCBvZiB0aGVzZSBhdHRyaWJ1dGVkIG1heSBiZSBjaGFuZ2VkIGFjY29yZGluZ2x5Lg0KDQoNCltL T10gSSBiYXNpY2FsbHkgYWdyZWUuIFRoZSBhdHRyaWJ1dGVzIHRpZWQgdG8gYSB3aG9sZSB2cG4g YW5kIGdsb2JhbGx5IGFwcGxpZWQgdG8gYWxsIHRoZSBzaXRlcyB1bmRlciB0aGUgdnBuIHNob3Vs ZCBiZSBkZWZpbmVkIHdpdGggdGhlIHZwbiBkZWZpbml0aW9uLg0KDQoNCjMuRm9yIGNvbnRhaW5l ciAidnBuIHBvbGljeSIgdGhhdCB1bmRlciBsaXN0ICJzaXRlcyIgaW4gY3VycmVudCBtb2RlbCwg dGhlcmUgYXJlIHR3byBpbmZvcm1hdGlvbiBkZWZpbmVkLCBvbmUgaXMgImZpbHRlciIgZm9yIHBy ZWZpeCBmaWx0ZXJpbmcsIGFub3RoZXIgaXMgInNpdGUtcm9sZSIuIEkgc3VnZ2VzdCB3ZSBzcGxp dCBpdCwgcHV0IHRoZSBsZWFmICJzaXRlLXJvbGUiIHVuZGVyIGxlYWYgInNpdGUtaWQiIGRpcmVj dGx5LCBhbmQgY2hhbmdlIHRoZSBuYW1lIG9mICJ2cG4tcG9saWN5IiB0byAic2l0ZS1wcmVmaXgt cG9saWN5Ii4gDQoNCiANCg0KVGhlIGZpbmFsIHN1Z2dlc3Qgc3RydWN0dXJlIG9mIHRoZSBMM1ZQ TiB5YW5nIG1vZGVsIHdpbGwgYmUgbG9vayBsaWtlIHRoZSBiZWxsb3csIEkgdW5kZXJsaW5lIHRo ZSBjaGFuZ2VkIHBvc2l0aW9ucyBmcm9tIHRoZSBjdXJyZW50IGwzdnBuIFlhbmcgTW9kZWwNCg0K IA0KDQpDb250YWluZXIgTDN2cG4tc3ZjDQoNCiAgIExpc3QgdnBuLXN2Yw0KDQogICBMZWFmIHZw bi1pZA0KDQogICBMZWFmIGN1c3RvbWVyLW5hbWUNCg0KICAgTGVhZiB0b3BvbG9neQ0KDQogICBM aXN0IGV4dHJhbmV0LXZwbi1wb2xpY3kNCg0KICAgQ29udGFpbmVyIGNsb3VkLWFjY2Vzcw0KDQog ICBMaXN0IG11bHRpY2FzdA0KDQogICBMZWFmIG1wbHMNCg0KICAgTGlzdCB0cmFuc3BvcnQtY29u dHJhaW50cw0KDQogICANCg0KICAgTGlzdCBzaXRlcw0KDQogICAgIExlYWYgc2l0ZS1pZA0KDQog ICAgIExlYWYgc2l0ZS1yb2xlDQoNCiAgICAgbGVhZiBhcHBseS10ZW1wbGF0ZQ0KDQogICAgIC4u LiAuLi4NCg0KICAgICAuLi4gLi4uDQoNCiAgICAgQ29udGFpbmVyIG1hbmFnZW50DQoNCiAgICAg Q29udGFpbmVyIHNpdGUtcHJlZml4LXBvbGljeQ0KDQogICAgIENvbnRhaW5lciBtYXhpbXVtLXJv dXRlcw0KDQogICAgIENvbnRhaW5lciBzZWN1cml0eQ0KDQogICAgIC4uLiAuLi4NCg0KICAgICAu Li4gLi4uDQoNCiAgICAgU2l0ZS1uZXR3b3JrLWFjY2VzcyANCg0KIA0KDQogDQoNCldoZXRoZXIg aXMgaXQgbW9yZSByZWFzb25hYmxlPyANCg0KIA0KDQogDQoNCkJlc3QgUmVnYXJkcy4NCg0KIA0K DQpBaWp1biBXYW5nDQoNCiANCg0KQ2hpbmEgVGVsZWNvbSBDb3Jwb3JhdGlvbiBMaW1pdGVkIEJl aWppbmcgUmVzZWFyY2ggSW5zdGl0dXRlIA0KDQpOZXR3b3JrIFJlc2VhcmNoIGFuZCBPcGVyYXRp b24gU3VwcG9ydCBEZXBhcnRtZW50DQoNCiANCg0KIA0KDQogDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgT2dha2ksIEtlbmljaGkNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxOCwgMjAx NiA5OjA4IEFNDQpUbzogbDNzbUBpZXRmLm9yZw0KU3ViamVjdDogW0wzc21dIElzc3VlICMxMCBS RTogTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGludGVyaW0g c2Vzc2lvbg0KDQogDQoNCkhpIFN0ZXBoYW5lIGFuZCBBbGwsDQoNCiANCg0KQXMgZm9yIGlzc3Vl ICMxMCBpdHNlbGYsIHRoZSBmb2xsb3dpbmcgc29sdXRpb24gY2FuIGJlIGFjY2VwdGFibGUgZm9y IHVzLg0KDQogDQoNCj5PbmUgcHJvcG9zYWwgY291bGQgYmUgdG8gbm90IGNhbGwgdGhpcyBWUE4g cG9saWN5LCBidXQgY3JlYXRpbmcgYQ0KDQo+Y29udGFpbmVyICJleHRyYW5ldC12cG4tcG9saWN5 IiBhdCB2cG4gbGV2ZWwgd2hpY2ggd2lsbCBtYW5kYXRlIGFuIGV4dHJhbmV0IFZQTiBhcmNoaXRl Y3R1cmUgZnJvbSBhIGNvbmZpZ3VyYXRpb24gcG9pbnQgb2YgdmlldywgZGVkdWNpbmcgYXV0b21h dGljYWxseSB0aGUgYXBwcm9wcmlhdGUgUlQgcnVsZXMgdG8gYWRkIChsaWtlIGNyZWF0aW5nIGEg bmV3IHBhaXIgb2YgUlRzKS4NCg0KIA0KDQpXaGF0IG1vZGVsIGlzIGluIHlvdXIgbWluZD8gSSBj YW4ndCBzZWUgd2hhdCAiImV4dHJhbmV0LXZwbi1wb2xpY3kiIGF0IHZwbiIgbWVhbnMuDQoNCkxp a2UgdGhpcz8NCg0KIA0KDQo8dnBuLXN2Yz4NCg0KICAgLi4uDQoNCiAgIDx2cG4tcG9saWN5Pg0K DQogICAgICAgPGVudHJpZXM+DQoNCiAgICAgICAgICAgPGlkPjE8L2lkPg0KDQogICAgICAgICAg IDx2cG4+DQoNCiAgICAgICAgICAgICAgIDx2cG4taWQ+VlBOMTwvdnBuLWlkPg0KDQogICAgICAg ICAgIDwvdnBuPg0KDQogICAgICAgICAgIDxleHRyYW5ldC12cG4tcG9saWN5Pg0KDQogICAgICAg ICAgICAgICA8ZXh0cmFuZXQtdnBuPg0KDQogICAgICAgICAgICAgICAgICAgPHZwbi1pZD5WUE4y PC92cG4taWQ+DQoNCiAgICAgICAgICAgICAgIDwvZXh0cmFuZXQtdnBuPg0KDQogICAgICAgICAg IDwvZXh0cmFuZXQtdnBuLXBvbGljeT4NCg0KICAgICAgIDwvZW50cmllcz4NCg0KICAgPC92cG4t cG9saWN5Pg0KDQogICAuLi4NCg0KPC92cG4tc3ZjPg0KDQogDQoNClRoYW5rcywNCg0KS2VuaWNo aQ0KDQogDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IEwzc20gW21haWx0 bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmc+IF0g T24gQmVoYWxmIE9mIHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIDxtYWlsdG86c3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb20+IA0KDQpTZW50OiBNb25kYXksIERlY2VtYmVyIDA3LCAy MDE1IDExOjQ1IFBNDQoNClRvOiBPZ2FraSwgS2VuaWNoaTsgJ0FpanVuIFdhbmcnOyAnUWluIFd1 JzsgbDNzbUBpZXRmLm9yZyA8bWFpbHRvOmwzc21AaWV0Zi5vcmc+IA0KDQpDYzogYWRyaWFuQG9s ZGRvZy5jby51ayA8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+IA0KDQpTdWJqZWN0OiBSZTog W0wzc21dIEwzU00gaW50ZXJpbSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRl cmltIHNlc3Npb24NCg0KIA0KDQpIaSBLZW5pY2hpLA0KDQogDQoNClJlZ2FyZGluZyB5b3VyIHBy b3Bvc2FsIG9mIGhhdmluZyBhIHNpbXBsZSBWUE4gcG9saWN5IGluIHRoZSB2cG4tc3ZjIGNvbnRh aW5lciwgSSBkbyBzZWUgYW4gaXNzdWUuIE9uZSBvZiB0aGUga2V5IHBvaW50IG9mIHRoZSBWUE4g cG9saWN5IGlzIHRvIGV4cHJlc3MgdGhlIHJvbGUgb2YgdGhlIHNpdGUgaW4gdGhlIHRhcmdldCBW UE4gdG9wb2xvZ3kuDQoNCklmIHdlIGRvIGEgdnBuIHBvbGljeSBhdCBWUE4gbGV2ZWwsIHdlIGNh bm5vdCBhbnltb3JlIGRlc2NyaWJlIHNpdGUgcm9sZXMgaW4gdGhlIHRhcmdldCBWUE4gd2hpY2gg Y2F1c2VzIGFuIGlzc3VlLg0KDQpJbiBhbiBpZGVhbCB3b3JsZCB3aGVyZSBhbGwgVlBOcyBhcmUg YW55IHRvIGFueSwgdGhlIHNpdGUgcm9sZSBpcyBhbHdheXMgdGhlIHNhbWUgYW5kIHRoZXJlIGlz IG5vIGlzc3VlLCBidXQgbGV0J3MgdGhpbmsgYWJvdXQgc29tZW9uZSB0cnlpbmcgdG8gdXNlIHRo ZSB2cG4tcG9saWN5IChhdCB2cG4gbGV2ZWwpIHRvIGNvbm5lY3QgdG8gYSBIdWIgJiBTcG9rZSBW UE4sIGhvdyBkbyB5b3UgZGVkdWNlIHRoZSByb2xlcyBvZiB0aGUgc2l0ZXMgPw0KDQogDQoNCk9u ZSBwcm9wb3NhbCBjb3VsZCBiZSB0byBub3QgY2FsbCB0aGlzIFZQTiBwb2xpY3ksIGJ1dCBjcmVh dGluZyBhIGNvbnRhaW5lciAiZXh0cmFuZXQtdnBuLXBvbGljeSIgYXQgdnBuIGxldmVsIHdoaWNo IHdpbGwgbWFuZGF0ZSBhbiBleHRyYW5ldCBWUE4gYXJjaGl0ZWN0dXJlIGZyb20gYSBjb25maWd1 cmF0aW9uIHBvaW50IG9mIHZpZXcsIGRlZHVjaW5nIGF1dG9tYXRpY2FsbHkgdGhlIGFwcHJvcHJp YXRlIFJUIHJ1bGVzIHRvIGFkZCAobGlrZSBjcmVhdGluZyBhIG5ldyBwYWlyIG9mIFJUcykuIFRo aXMgbWVhbnMgdGhhdCB0aGUgdXNhZ2UgaXMgcmVhbGx5IGxpbWl0ZWQgdG8gInNpbXBsZSIgZXh0 cmFuZXQtdnBucyBhbmQgaXQgZG9lcyBub3QgcmVwbGFjZSBub3IgY29tcGV0ZSB3aXRoIHRoZSBW UE4gcG9saWN5IGF0IHNpdGUgbGV2ZWwuDQoNCiANCg0KQ291bGQgaXQgYmUgYSBnb29kIGNvbXBy b21pc2UgPw0KDQogDQoNClN0ZXBoYW5lDQoNCiANCg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KDQpGcm9tOiBPZ2FraSwgS2VuaWNoaSBbbWFpbHRvOmtlLW9vZ2FraUBrZGRpLmNv bSA8bWFpbHRvOmtlLW9vZ2FraUBrZGRpLmNvbT4gXQ0KDQpTZW50OiBTYXR1cmRheSwgRGVjZW1i ZXIgMDUsIDIwMTUgMDY6MjMNCg0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvT0lOSVM7ICdB aWp1biBXYW5nJzsgJ1FpbiBXdSc7IGwzc21AaWV0Zi5vcmcgPG1haWx0bzpsM3NtQGlldGYub3Jn PiANCg0KQ2M6IGFkcmlhbkBvbGRkb2cuY28udWsgPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVr PiANCg0KU3ViamVjdDogUkU6IFtMM3NtXSBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9u IFRodXJzZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCiANCg0KRGVhciBTdGVwaGFuZSBhbmQg QWxsLA0KDQogDQoNCkkgZG9uJ3Qgc2F5IHRoYXQgc2l0ZXMgKm11c3QqIG1vdmUgdW5kZXIgdnBu LXN2YyBiZWNhdXNlIEkgdW5kZXJzdGFuZCBzdGVwaGFuZSdzIHVzZSBjYXNlLg0KDQpCdXQgd2Ug YWxyZWFkeSBoYXZlIHZwbi1zdmMgYW5kIHNvbWUgcGFyYW1ldGVycyB1bmRlciB0aGlzIGFyZSBn bG9iYWxseSBhcHBsaWVkIHRvIGFsbCB0aGUgc2l0ZXMgZXZlbiBpbiB0aGUgY3VycmVudCBtb2Rl bC4NCg0KIA0KDQpJdCBkZXBlbmRzIG9uIG9wZXJhdG9yJ3MgdXNlIGNhc2Ugd2hpY2ggaXMgc2l0 ZS1vcmllbnRlZCBvciB2cG4tb3JpZW50ZWQgc2VydmljZS4NCg0KT3VyIHNlcnZpY2UgaXMgdnBu LW9yaWVudGVkLCBzaXRlIGhhcyB0aGUgbmF0aXZlIFZQTi4gVGhlbiwgSSB3b3VsZCBqdXN0IGxp a2UgeW91IHRvIGFsbG93IG90aGVyIGdsb2JhbCBvcHRpb25zIHRvIHZwbi1zdmMuDQoNCiANCg0K VGhhbmtzLA0KDQpLZW5pY2hpDQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0K RnJvbTogc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20gPG1haWx0bzpzdGVwaGFuZS5saXRr b3dza2lAb3JhbmdlLmNvbT4gIFttYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20g PG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gXQ0KDQpTZW50OiBGcmlkYXks IERlY2VtYmVyIDA0LCAyMDE1IDg6MTcgUE0NCg0KVG86IEFpanVuIFdhbmc7ICdPZ2FraSwgS2Vu aWNoaSc7ICdRaW4gV3UnOyBsM3NtQGlldGYub3JnIDxtYWlsdG86bDNzbUBpZXRmLm9yZz4gDQoN CkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrIDxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4gDQoN ClN1YmplY3Q6IFJFOiBbTDNzbV0gTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVy c2RheSBMM1NNIGludGVyaW0gc2Vzc2lvbg0KDQogDQoNCkhpLA0KDQogDQoNCkknbSBhZ2FpbnN0 IHRoaXMgcHJvcG9zYWwsIGFzIEkgZG8gbm90IHdhbnQgdG8gY3JlYXRlIGFueSBkZXBlbmRlbmN5 IGJldHdlZW4gYSBwYXJ0aWN1bGFyIFZQTiBhbmQgYSBsaXN0IG9mIHNpdGVzLg0KDQpBIHNpdGUg Y2FuIGJlbG9uZyB0byBtdWx0aXBsZSBWUE5zIHdpdGggYW55IGtpbmQgb2YgdG9wb2xvZ3ksIGlm IHdlIGF0dGFjaCB0aGUgc2l0ZSB0byBhIHNpbmdsZSBWUE4sIHdlIGNvbWUgYmFjayB0byB0aGUg bm90aW9uIG9mICJuYXRpdmUgVlBOIiB3ZSBoYWQgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgbW9k ZWwgd2hpY2ggd2FzIGhhcmQgdG8gdW5kZXJzdGFuZCBhbmQgc28gd2FzIHJlbW92ZWQuDQoNCiAN Cg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBMM3NtIFttYWlsdG86 bDNzbS1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnPiBdIE9u IEJlaGFsZiBPZiBBaWp1biBXYW5nDQoNClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDQsIDIwMTUg MDI6NDQNCg0KVG86ICdPZ2FraSwgS2VuaWNoaSc7ICdRaW4gV3UnOyBsM3NtQGlldGYub3JnIDxt YWlsdG86bDNzbUBpZXRmLm9yZz4gDQoNCkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrIDxtYWlsdG86 YWRyaWFuQG9sZGRvZy5jby51az4gDQoNClN1YmplY3Q6IFJlOiBbTDNzbV0gTDNTTSBpbnRlcmlt IG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGludGVyaW0gc2Vzc2lvbg0KDQogDQoN CkRlYXIgYWxsOg0KDQogDQoNCkNhbiB3ZSBwdXQgdGhlIGxpc3QgInNpdGVzIiB3aXRoaW4gdGhl IGxpc3QgInZwbi1zdmMiLCBhbmQgZGVmaW5lIHRoZSBnZW5lcmFsIHZwbiBwb2xpY3kgZm9yIGFs bCBzaXRlcyB0aGF0IHdpdGhpbiB0aGUgY29ycmVzcG9uZGluZyB2cG4gc2VydmljZSBpbnN0YW5j ZT8NCg0KSWYgZG9pbmcgc28sIHNvbWUgZW50cmllcyB3aXRoaW4gdGhlIGN1cnJlbnQgbGlzdCAi c2l0ZXMiIGNhbiBhbHNvIGJlIGRyYWdnZWQgb3V0IGZvciBnZW5lcmFsIHVzdWFsIHB1cnBvc2Vz LCBmb3IgZXhhbXBsZSwgIm1heGltdW0tcm91dGVzIiwgInNlY3VyaXR5IiBldGMuIFRoZXNlIHBh cmFtZXRlcnMgYXJlIG9mdGVuIGFsbCBzYW1lIGZvciBldmVyeSBzaXRlIHdpdGhpbiBvbmUgVlBO IHNlcnZpY2UgaW5zdGFuY2UuIA0KDQogDQoNCklmIHNvbWUgc2l0ZXMgaGF2ZSBzcGVjaWFsIHJl cXVpcmVtZW50cywgd2UgY2FuIGFjaGlldmUgdGhpcyBieSB1c2luZyBzb21lIHNwZWNpYWwgInNp dGUtdnBuLXBvbGljeSIgd2l0aGluIHRoZSBjb3JyZXNwb25kaW5nIHNpdGUgZGVmaW5pdGlvbi4N Cg0KSXMgdGhpcyBtb3JlIGFjY2VwdGFibGUgZm9yIGN1c3RvbWVycz8NCg0KIA0KDQogDQoNCkJl c3QgUmVnYXJkcy4NCg0KIA0KDQpBaWp1biBXYW5nDQoNCiANCg0KQ2hpbmEgVGVsZWNvbSBDb3Jw b3JhdGlvbiBMaW1pdGVkIEJlaWppbmcgUmVzZWFyY2ggSW5zdGl0dXRlIEludGVsbGlnZW50IE5l dHdvcmsgUHJvZHVjdCBMaW5lDQoNCiANCg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86bDNz bS1ib3VuY2VzQGlldGYub3JnPiBdIE9uIEJlaGFsZiBPZiBPZ2FraSwgS2VuaWNoaQ0KDQpTZW50 OiBGcmlkYXksIERlY2VtYmVyIDA0LCAyMDE1IDk6MDIgQU0NCg0KVG86ICdRaW4gV3UnOyBsM3Nt QGlldGYub3JnIDxtYWlsdG86bDNzbUBpZXRmLm9yZz4gDQoNCkNjOiBhZHJpYW5Ab2xkZG9nLmNv LnVrIDxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4gDQoNClN1YmplY3Q6IFJlOiBbTDNzbV0g TDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGludGVyaW0gc2Vz c2lvbg0KDQogDQoNCkRlYXIgQWxsLA0KDQogDQoNCkl0IHdhcyBnb29kIGhhdmluZyBkaXNjdXNz aW9uLg0KDQogDQoNCkFzIGZvciBpc3N1ZSMxMCwgdGhlIG9iamVjdGl2ZSBhbmQgcHJvYmxlbSB3 ZSBkaXNjdXNzZWQgaW4gdGhlIG1lZXRpbmcgYXMgZm9sbG93cy4NCg0KIA0KDQpUaGUgb2JqZWN0 aXZlIGlzIHRvIHByb3ZpZGUgcGVyLVZQTiBleHRyYW5ldCBzZXJ2aWNlIHdoaWNoIGNvbm5lY3Rz IHR3byBkaWZmZXJlbnQgVlBOcyAoZS5nLiBWUE4xIGFuZCBWUE4yKS4gSXQgbWVhbnMgdGhhdCBh bnkgc2l0ZXMgaW4gVlBOMSBjYW4gYWNjZXNzIHRvIGFueSBzaXRlcyBpbiBWUE4yLg0KDQpUaGUg cHJvYmxlbSBpcyB0aGF0IHRoZSBjdXJyZW50IG1vZGVsIG11c3QgdXBkYXRlIHZwbi1wb2xpY3kg dW5kZXIgYWxsIHRoZSBzaXRlcyBiZWxvbmcgdG8gdGhlc2UgdHdvIFZQTnMgaW4gb3JkZXIgdG8g b2ZmZXIgdGhpcyBzZXJ2aWNlLiBFc3BlY2lhbGx5IHdoZW4gdGhpcyBtb2RlbCBpcyB1c2VkIGFz IGEgY3VzdG9tZXIgc2VsZi1jb250cm9sIEFQSSwgaXQncyBub3QgZ29vZCBpZGVhIHRvIHJlcXVp cmUgY3VzdG9tZXJzIHRvIHVwZGF0ZSB0aGUgaW5mb3JtYXRpb24gb2YgYWxsIHRoZSBzaXRlcy4g KEl0J3Mgbm90IGFic3RyYWN0ZWQgd2F5LCBhIHNlcnZpY2UgbW9kZWwgc2hvdWxkIHByb3ZpZGUg d2hhdCB0aGUgY29uc3VtZXIgd2FudHMsIG5vdCBob3cuKSBJZiBhIHNlcnZpY2Ugb3IgY3VzdG9t ZXIgcmVxdWlyZXMgdG8gY29udHJvbCBwZXItc2l0ZSB2cG4tcG9saWN5LCB0aGF0IG9mIGN1cnJl bnQgbW9kZWwgc2hvdWxkIGJlIHVzZWQgd2l0aG91dCBzZXR0aW5nIHBlci1WUE4gdnBuLXBvbGl0 eS4gSXQgZGVwZW5kcyBvbiBlYWNoIG9wZXJhdG9yJ3Mgc2VydmljZS4NCg0KU3RlcGhhbmUgcHJv cG9zZWQgdG8gdXNlIGFwcGx5LXRlbXBsYXRlLCBidXQgaXQgc3RpbGwgY2Fubm90IHNvbHZlIHRo ZSBwcm9ibGVtLiBXaGVuIGVhY2ggVlBOIGFscmVhZHkgaGFzIGEgbGFyZ2UgbnVtYmVyIG9mIHNp dGVzIGFuZCB3YW50IHRvIGNvbm5lY3QgZWFjaCBvdGhlciBmb3IgdGhlIGZpcnN0IHRpbWUsIGJv dGggVlBOcyBtdXN0IHVwZGF0ZSB0aGVzZSBzaXRlcyB0byBhcHBseSBhcHBseS10ZW1wbGF0ZSBv biB0aGUgY3VycmVudCBtb2RlbC4NCg0KIA0KDQpUaGFua3MsDQoNCktlbmljaGkNCg0KIA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3Vu Y2VzQGlldGYub3JnIDxtYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnPiBdIE9uIEJlaGFsZiBP ZiBRaW4gV3UNCg0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAwNCwgMjAxNSAxMjo0MiBBTQ0KDQpU bzogbDNzbUBpZXRmLm9yZyA8bWFpbHRvOmwzc21AaWV0Zi5vcmc+IA0KDQpDYzogYWRyaWFuQG9s ZGRvZy5jby51ayA8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+IA0KDQpTdWJqZWN0OiBbTDNz bV0gTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGludGVyaW0g c2Vzc2lvbg0KDQogDQoNCkhpIGFsbDoNCg0KIA0KDQogDQoNCkJlbG93IGlzIHRoZSBpbml0aWFs IHZlcnNpb24gb2YgZHJhZnQgbWludXRlcyBmb3IgVGh1cnNkYXkgTDNTTSBXRyBpbnRlcmltIHNl c3Npb24uDQoNCiANCg0KVGhhbmtzIERhbiB0byBoZWxwIHRha2UgbWludXRlcy4NCg0KIA0KDQpG b2xrcywgcGxlYXNlIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb3JyZWN0aW9uLg0KDQog DQoNCiANCg0KLVFpbg0KDQogDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KIA0KDQpMM1NN IFdvcmtpbmcgR3JvdXAgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcgDQoNCiANCg0KVGh1cnNkYXkg RGVjZW1iZXIgNXRoLCAyMDE1LiA4YW0gRWFzdCBDb2FzdCBUaW1lIChOZXcgWW9yaykNCg0KIA0K DQogDQoNCkJMVUUgU0hFRVQNCg0KIA0KDQogDQoNCk5hbWUgICAgICAgICAgICAgICAgICAgIHwg QWZmaWxpYXRpb24NCg0KIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0NCg0KIA0KDQpBZHJpYW4gRmFycmVsICAgICAgICAgICB8IE9sZCBEb2cgQ29uc3Vs dGluZw0KDQogDQoNClFpbiBXdSAgICAgICAgICAgICAgICAgIHwgSHVhd2VpIFRlY2hub2xvZ2ll cw0KDQogDQoNClN0ZXBoYW5lIExpdGtvd3NraSAgICAgIHwgT3JhbmdlDQoNCiANCg0KTHVpcyBU b21vdGFraSAgICAgICAgICAgfCBWZXJpem9uDQoNCiANCg0KRGFuaWVsIEtpbmcgICAgICAgICAg ICAgfCBPbGQgRG9nIENvbnN1bHRpbmcNCg0KIA0KDQpTdXNhbiBIYXJlcyAgICAgICAgICAgICB8 IEh1YXdlaSBUZWNobm9sb2dpZXMNCg0KIA0KDQpTY290dCBNYW5zZmllbGQgICAgICAgICB8IEVy aWNzc29uDQoNCiANCg0KR3UgUm9uZyAgICAgICAgICAgICAgICAgfCBDaGluYSBNb2JpbGUgDQoN CiANCg0KS2VuaWNoaSBPZ2FraSAgICAgICAgICAgfCBLRERJDQoNCiANCg0KQWlqdW4gV2FuZyAg ICAgICAgICAgICAgfCBDaGluYSBUZWxlY29tDQoNCiANCg0KVmljdG9yIFNhbnRvcyAgICAgICAg ICAgfCBFcmljc3Nvbg0KDQogDQoNCklnbmFzIEJhZ2RvbmFzICAgICAgICAgIHwgDQoNCiANCg0K IA0KDQogDQoNCiANCg0KIA0KDQogDQoNCiANCg0KIA0KDQogDQoNCk1JTlVURVMNCg0KIA0KDQog DQoNCiogTWV0aW5nIGxvZ2lpc3RpY3MgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L21zZy9sM3NtL1NKdWIxYUhWUUdPUVc2cldodGhYMGZCOEFjOCA8aHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9sM3NtL1NKdWIxYUhWUUdPUVc2cldodGhYMGZCOEFjOD4gIA0K DQogDQoNCiogTWVldGluZyBtYXRlcmlhbHMgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvaW50ZXJpbS8yMDE1LzEyLzAzL2wzc20vcHJvY2VlZGluZ3MuaHRtbCA8aHR0cHM6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1LzEyLzAzL2wzc20vcHJvY2VlZGluZ3Mu aHRtbD4gIA0KDQogDQoNCiogRXRoZXJwYWQgZm9yIG1pbnV0ZXMgKHRoaXMgcGFnZSkgaHR0cDov L2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9sM3NtLWludGVyaW0tMjAxNS0xMi0wMyA8 aHR0cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9sM3NtLWludGVyaW0tMjAxNS0x Mi0wMz4gDQoNCiANCg0KKiBKYWJiZXIgdXNpbmcgbDNzbUBqYWJiZXIuaWV0Zi5vcmcgPG1haWx0 bzpsM3NtQGphYmJlci5pZXRmLm9yZz4gDQoNCiANCg0KKiBCbHVlIHNoZWV0IGh0dHA6Ly9ldGhl cnBhZC50b29scy5pZXRmLm9yZzo5MDAwL3AvbDNzbS1pbnRlcmltLTIwMTUtMTItMDMtYmx1ZXNo ZWV0IDxodHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9wL2wzc20taW50ZXJpbS0y MDE1LTEyLTAzLWJsdWVzaGVldD4gDQoNCiANCg0KIA0KDQpBZ2VuZGFhDQoNCiANCg0KLSBBZG1p bmlzdHJpdmlhIChOb3RlIFdlbGwsIGV0YykuIGENCg0KIA0KDQotIEludHJvZHVjdGlvbg0KDQog DQoNCi0gT3BlbiBJc3N1ZXMgZm9yIFlBTkcgRGF0YSBNb2RlbCBmb3IgTDNWUE5zZXJ2aWNlIGRl bGl2ZXJ5IChkcmFmdC1pZXRmLWwzc20tbDN2cG4tc2VydmljZW1vZGVsKQ0KDQogDQoNCm8gT3Bl biBJc3N1ZXMgZGlzY3Vzc2lvbiBhbmQgcmVzb2x1dGlvbuKAkyBodHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy93Zy9sM3NtL3RyYWMvcmVwb3J0LzEgPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L3dnL2wzc20vdHJhYy9yZXBvcnQvMT4gDQoNCiANCg0KIA0KDQpGb3IgYSBmdWxsIGxpc3Qgb2Yg aXNzdWVzIGFuZCByZXNvbHV0aW9uIHByb3Bvc2FscyBwbGVhc2Ugc2VlOiBodHRwczovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTUvMTIvMDMvbDNzbS9zbGlkZXMvc2xpZGVz LWludGVyaW0tMjAxNS1sM3NtLTEtMi5wZGYgPGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzL2ludGVyaW0vMjAxNS8xMi8wMy9sM3NtL3NsaWRlcy9zbGlkZXMtaW50ZXJpbS0yMDE1LWwz c20tMS0yLnBkZj4gDQoNCiANCg0KIA0KDQpJc3N1ZSMxOiBXaGVuIGN1c3RvbWVyLW5hdC1hZGRy ZXNzIGlzIHVzZWQNCg0KIA0KDQpSZXNvbHV0aW9uICMxOiAgTGVhZiB1c2VkIHdoZW4gTkFUIGlz IHJlcXVpcmVkIHRvIGFjY2VzcyBjbG91ZCBWUE4gYW5kIGN1c3RvbWVyIHdhbnRzIHRvIHVzZSBp dHMgb3duSVAgYWRkcmVzcy4gSWYgcHJvdmlkZXIgcHJvdmlkZXMgdGhlIHB1YmxpYyBJUCxubyBu ZWVkIHRvIHVzZSB0aGUgbGVhZg0KDQogDQoNClN0YXR1cyAjMTogIENsb3NlZCBQZW5kaW5nIEkt RCB0ZXh0IHJldmlldy4gICANCg0KIA0KDQpEaXNjdXNzaW9uIG9uICMxOiANCg0KIA0KDQogDQoN CkFpanVuIGFza3MgZm9yIG1vcmUgZGVzY3JpcHRpb24gaW4gdGhlIFlBTkcgbW9kZWwgaXRzZWxm DQoNCiANCg0KU3RlcGhhbmUgc2hvd3MgY3VycmVudCBtb2RlbA0KDQogDQoNCkFncmVlZCBPSw0K DQogDQoNCiANCg0KSXNzdWUjMiA6IElkZW50aWZ5IGwzdnBuIHN2YyB1c2luZyBpZCBvciBuYW1l IG9yIGJvdGgNCg0KIA0KDQpSZXNvbHV0aW9uICMyOiAgSUQgaXMgYSBzdHJpbmcsIGFzIHBlciBv dGhlciBwcm9wZXJ0aWVzIGluIHRoZSBtb2RlbA0KDQogDQoNClN0YXR1cyAjMjogQ2xvc2VkDQoN CiANCg0KRGlzY3Vzc2lvbiBvbiAjMjogDQoNCiANCg0KIA0KDQpBZ3JlZWQgT0sNCg0KIA0KDQog DQoNCklzc3VlIzM6IE0gdG8gTiBhdmFpbGFiaWxpdHkgc3VwcG9ydA0KDQogDQoNClJlc29sdXRp b24gIzM6IE1vZGVsaW5nIHNpdGVzIHVzaW5nIGEgbGlzdCB3aXRoIGEgcHJpb3JpdHksIHNvIGlu Y2x1ZGUgYWNjZXNzIGxpc3Qgd2l0aCBhIHByaW9yaXR5Lg0KDQogDQoNClN0YXR1cyAjMzoNCg0K IA0KDQpEaXNjdXNzaW9uIG9uICMzOiANCg0KIA0KDQogDQoNClFpbiB3YXMgYXNraW5nIHRoYXQg TSB0byBOIGF2YWlsYWJpbGl0eSBpcyBzdXBwb3J0ZWQgd2l0aCBhY2Nlc3MgYW5kIHByaW9yaXR5 IG51bWJlci4gDQoNCiANCg0KU3RlcGhhbmUgc3RhdGVkIHRoaXMgaXMgc3VwcG90ZWQuIFRoaXMg bmV3IHByb3Bvc2FsIGFsc28gc3VwcG9ydHMgbXVsdGlwbGUgc2l0ZXMsIGFzIGEgbGlzdC4NCg0K IA0KDQpRaW4gYWxzbyBhc2tlZCBpZiBHcm91cCBJLUQgd2FzIG5vIGxvbmdlciBuZWVkZWQsIHdo aWNoIGl0IGlzIG5vdC4gQWxzbyBnb29kIHNvbHV0aW9uIHN1cHBvcnRlZCBieSBvdGhlciBvcGVy YXRvcnMuDQoNCiANCg0KU3RlcGhhbmUgYXNrZWQgaWYgZm91ciBwcmlvcml0aWVzIHdhcyBlbm91 Z2gsIG9yIGlmIG1vcmUgd2VyZSBuZWVkZWQuIA0KDQogDQoNCiANCg0KUmU6IENvbnRhaW5lcnMv UHJvcGVydGllcyBmb3IgTmV0d29yayBBY2Nlc3MgQ29uZmlndXJhdGlvbiAtIENvbmNsdXNpb25z Pw0KDQogDQoNCiANCg0KbyBMb2NhdGlvbiAtIERpZmZlcmVudCBzaXRlIEktRD8NCg0KIA0KDQpv IFFvUyBQb2xpY3kgLSBQZXIgbmV0d29yayBhY2Nlc3MgbGluaywgb3Igc2l0ZSBpbmZvcm1hdGlv bj8gV291bGQgUW9TIChjb3N0KSBiZSBkaWZmZXJlbnQgcGVyIGFjY2Vzc2xpbmsgb3Igc2l0ZT8g RXhhbXBsZSBvZiBQcmltYXJ5IGFuZCBCYWNrdXAgbGlua3MgZ2l2ZW4uIA0KDQogDQoNCm8gQmFu ZHdpZHRoIC0gTW92ZWQgdG8gYWNjZXNzIGxpbmsgZ3JvdXAgDQoNCiANCg0KbyBNYXhpbXVtIFJv dXRlcyAtIA0KDQogDQoNClNlY3VyaXR5LCByb3V0aW5nLCBhbmQgc2VydmljZXMgYXJlIGR1cGxp Y2F0ZWQgd2l0aCBpbmhlcml0YW5jZQ0KDQogDQoNCiANCg0KIA0KDQpJc3N1ZSM0OiBzaXRlLXNl cnZpY2UtY2xvdWQgYWNjZXNzIGFzIGdyb3VwaW5nDQoNCiANCg0KUmVzb2x1dGlvbiAjNCBBbHJl YWR5IHJlc2lsdmVkIGFzIGEgc2VwYXJhdGUgZ3JvdXBpbmcNCg0KIA0KDQpTdGF0dXMgIzQ6IENs b3NlZA0KDQogDQoNCkRpc2N1c3Npb24gb24gIzQ6IA0KDQogDQoNCiANCg0KSXNzdWUjNTogTXVs dGljYXN0IHN1cHBvcnQgYXMgcmFpc2VkIGJ5IEVyaWMgUm9zZW4NCg0KIA0KDQpSZXNvbHV0aW9u ICM1OiA6IE5ldyAicHJvdmlkZXIgbWFuYWdlZCIgcHJvcGVydHksIGFuZCBpbiBTaXRlIFByb3Bl cnRpZXMgInByb3BlcnR5LXR5cGUiICBhZGRlZA0KDQogDQoNClN0YXR1cyAjNTogU29sdXRpb24g cHJvcG9zZWQuIA0KDQogDQoNCkRpc2N1c3Npb24gb24gIzU6IA0KDQogDQoNCiANCg0KU3RlcGhh bmUgd2lsbCBwcm92aW9kZSBuZXcgcHJvcGVydHkgcHJvcG9zYWxzIHdpbGwgYmUgcHJvdmlkZWQg dG8gRXJpYyBmb3IgcmV2aWV3LiANCg0KIA0KDQogDQoNCklzc3VlIzY6IEludmVudG9yeSBvcGVy YXRpb25hbCBzdGF0ZQ0KDQogDQoNClJlc29sdXRpb24gIzY6IEluY2x1ZGUgYSBuZXcgY29udGFp bmVyIGZvciBpbnZlbnRvcnkgc3RhdGUsIG9yIGFuIFJQQyBjYWxsIChzaXR0aW5nIGFib3ZlIHRo ZSBzZXJ2aWNlIG9yY2hlc3RyYXRvcikgdG8gcmV0cmlldmUgaW52ZW50b3J5IHN0YXRlLiANCg0K IA0KDQpTdGF0dXMgIzY6IE5lZWQgdG8gcHJvcG9zZSB0byB0aGUgV0cgYW5kIGFncmVlIHNvbHV0 aW9uLg0KDQogDQoNCkRpc2N1c3Npb24gb24gIzY6IA0KDQogDQoNCiANCg0KTHVpcyBhc2tlZCB3 b3VsZCB0aGlzIGluZm8gYmUgY29sbGVjdGVkIGZyb20gcHJvdmlzaW9uIHN0YXRlPyBTdGVwaGFu ZSBzdWdnZXN0ZWQgdGhpcyB3b3VsZCBub3QgYmUgYXZhaWxpYmxlLiANCg0KIA0KDQpBZHJpYW4g b2JzZXJ2ZWQgdGhhdCB0aGUgY29kZSB1c2VkIHRvIGNvbnZlcnQgdGhlIG1vZGVsIGludG8gYSBz ZXJ2aWNlIHJlcXVlc3QgbWF5IG5vdCB1dGlsaXNlIHRoaXMgaW52ZW50b3J5IGluZm9ybWF0aW9u IGNhcGFiaWxpdHkuIFN1ZSBtZW50aW9uZWQgdGhhdCBvdGhlcnMgaGF2ZSBtZW50aW9uZWQgYnkg YSB2ZW5kb3IgdGhhdCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSB0aGUgYWJpbGl0eSB0byBj b25maWd1cmUgaW52ZW50b3J5IHN0YXRlLiBUaGlzIHNob3VsZCBiZSBjbGFyaWZpZWQgYnkgdGhl IG9wZXJhdG9ycy4gDQoNCiANCg0KIA0KDQpTdGVwaGFuZSB0byB0YWtlIHByb3Bvc2FscyB0byBs aXN0IGFuZCBhc2sgYW55b25lIHdobyBpcyBpbnRlcmVzdGVkIGluIGhhdmluZyB0aGUgZmVhdHVy ZSB0byBzdWdnZXN0IHRleHQuDQoNCiANCg0KIA0KDQogDQoNCklzc3VlIzc6IEdlbmVyaWMgVkFT IC0gZG8gd2UgbmVlZCB0byBjcmVhdGUgYSBnZW5lcmljIFZBUyBjb250YWluZXIgYXMgVkFTIGFy ZSBwb3B1bGFyIGluIEwzVlBOcz8NCg0KIA0KDQpSZXNvbHV0aW9uICM3OiBTZXBhcmF0ZSBmcm9t IEwzU00NCg0KIA0KDQpTdGF0dXMgIzc6IENsb3NlZA0KDQogDQoNCkRpc2N1c3Npb24gb24gIzc6 IA0KDQogDQoNCiANCg0KR3UgUm9uZyBoaWdobGlnaHRlZCBHZW5lcmljIFZBUyBtb2RlbCB3aGlj aCB3YXMgcHJlc2VudGVkIGF0IElFVEYgOTQuIA0KDQogDQoNCiANCg0KSXNzdWUjODogV2hvIGtl ZXBzIHNpdGUgbG9jYXRpb25pbmZvcm1hdGlvbj8NCg0KIA0KDQpSZXNvbHV0aW9uICM4OiBUZXh0 IGhhcyBiZWVuIGZpeGVkDQoNCiANCg0KU3RhdHVzICM4OiBDbG9zZWQNCg0KIA0KDQpEaXNjdXNz aW9uIG9uICM4OiANCg0KIA0KDQogICAgDQoNCiANCg0KSXNzdWUjOTogRG8gd2UgbmVlZCB0byBt b2RlbCB0cmFuc3BvcnQgY29uc3RyYWludHMsIHN1Y2ggYXM6IGppdHRlciwgZGlzam9pbnQsIHBh dGggZGl2ZXJzaXR5Pw0KDQogDQoNClJlc29sdXRpb24gIzk6ICAgUHJvcG9zZSBhICJ0cmFuc3Bv cnQtY29uc3RyYWludCIgZ3JvdXAgd2l0aCAiY29uc3RyYWludC10eXBlIiwgImNvbnN0cmFpbnQt dmFsdWUiIGFuZCAiY29uc3RyYWludC1saXN0IiAoY29tcG9zZWQgb2YgdHlwZSBhbmQgdmFsdWVz KQ0KDQogDQoNClN0YXR1cyAjOTogQXV0aG9ycyB0byBwcm9wb3NlIHRoZSByZXNvbHV0aW9uIGlu IHRoZSBJLUQgYW5kIHByb3ZpZGUgdG8gdGhlIFdHDQoNCiANCg0KRGlzY3Vzc2lvbiBvbiAjOTog ICAgDQoNCiANCg0KIA0KDQogDQoNCkx1aXMgbWVudGlvbmVkIHRoYXQgdGhleSBoYXZlIG11bHRp Y2FzdCB0cmFuc3BvcnQgKG11bHRpcGxlIHNpdGVzKSBhbmQgYmktZGlyZWN0aW9uYWwgdHJhZmZp YyBhcHBsaWNhdGlvbnMgKGZpbmFuY2lhbCkgdGhhdCB3aWxsIHJlcXVpcmUgdHJhbnNwb3J0IGNv bnN0cmFpbnRzDQoNCiANCg0KIA0KDQpEdXBsaWNhdGUgdHJhbnNwb3J0IGNvbnN0cmFpbnRzIGZv ciB1bmljYXN0IGFuZCBtdWx0aWNhc3QgdG8gZ2l2ZSBvcHRpb25zIGZvciBzZXBhcmF0ZSBjb25m aWd1cmF0aW9uLg0KDQogDQoNCktlZXAgc2luZ2xlIGxpc3QgZW50cmllcyBmb3IgZWFjaCBzcmMv ZHN0IHBhaXIgZXZlbiBpbiB0aGUgbXVsdGljYXN0IHZhcmlhbnQuDQoNCiANCg0KIA0KDQpETyB3 ZSBuZWVkIHRvIHN1cHBvcnQgbXVsdGlwbGUgY29uc3RyYWludHMgb3IganVzdCBoYXZlIGEgc2lu Z2xlIGNvbXBvc2l0ZSAob2YgbXVsdGlwbGUgY29uc3RyYWludHMpLCBoYXZlIHRoZSBhYmlsaXR5 IHRvIHNwZWNpZnkgYSBjb25zdHJhaW50LWxpc3Q/DQoNCiANCg0KQWlqdW4gcHJmZXJzIGxpc3Qg b2YgY29uc3RyYWludHMgYW5kIG1lZXRpbmcgYWdyZWVzIHRoaXMgaXMgT0sNCg0KIA0KDQogDQoN CldoYXQgY29uc3RyYWludHMgdG8gb2ZmZXI/DQoNCiANCg0KTGF0ZW5jeQ0KDQogDQoNClBhdGgg ZGl2ZXJzdHkNCg0KIA0KDQpTaXRlIGRpdmVyc3R5DQoNCiANCg0KSml0dGVyDQoNCiANCg0KQ2xh c3Mgb2Ygc2VydmljZSB3YXMgcHJvcG9zZWQgYnV0IHJlamVjdGVkDQoNCiANCg0KIA0KDQpMdWlz IGhpZ2hsaWdodGVkIHRoZXkgaGF2ZSBhIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gdGhhdCB1c2Vz IHRoZSBzaW1pbGFyIHByb3Bvc2FsLiBMdWlzIGFsc28gbWVudGlvbmVkIHRoYXQgc2l0ZSBkaXZl cnNpdHkgbWlnaHQgYWxzbyBiZSByZXF1aXJlZCwgd291bGQgdGhpcyBiZSBhY2hpZXZhYmxlDQoN CiANCg0KIA0KDQogDQoNCklzc3VlIzEwOiBWUE4gIm1lcmdpbmciDQoNCiANCg0KUmVzb2x1dGlv biAjMTA6ICAgIA0KDQogDQoNClN0YXR1cyAjMTA6DQoNCiANCg0KRGlzY3Vzc2lvbiBvbiAjMTA6 ICAgIA0KDQogDQoNCiANCg0KVlBOIGlzIGEgcGVyIHNpdGUgcHJvcGVydHkuIA0KDQogDQoNCi0g QSBzaXRlIGNhbiBiZWxvbmcgdG9tdWx0aXBsZSBWUE5zDQoNCiANCg0KLSBIb3cgdG8gaGFuZGxl IG1lcmdpbmcgb2YgdHdvIFZQTnM/DQoNCiANCg0KLSBJcyB0aGlzIGFuIGlzc3VlIHRoZSBzZXJ2 aWNlIG1vZGVsIGhhcyB0byBkZWFsIHdpdGg/DQoNCiANCg0KIA0KDQpJZiBWUE4gbWVyZ2luZyBp cyByZXF1aXJlZCB0byBiZSBzZWFtbGVzcywgdGhlbiB0aGlzIHdvdWxkIGJlIGRldmljZSBzcGVj aWZpYyBhbmQgbm90IHNlcnZpY2UgbW9kZWwgcmVsYXRlZC4gIA0KDQogDQoNCiANCg0KIk1lcmdp bmciIGlzIGEgY29uZnVzaW5nIHRlcm0uIFRoZSBvYmplY3RpdmUgaXMgTk9UIHRvIG1lcmdlIFZQ TjEgYW5kIFZQTjIuDQoNCiANCg0KVGhlIG9iamVjdGl2ZSBpcyB0byBwcm92aWRlIGFuIGV4dHJh bmV0IHNvIHRoYXQgc29tZSBzaXRlcyBpbiBWUE4xIGNhbiBjb25uZWN0IHRvIHNvbWUgc2l0ZXMg aW4gVlBOMiBmb3Igc29tZSB0cmFmZmljLg0KDQogDQoNClRoaXMgY2FuIGJlIHNvbHZlZCB1c2lu ZyBhIHBlci1zaXRlIHByb3BlcnR5Lg0KDQogDQoNCiANCg0KQWN0aW9uOiBOZWVkIHRvIHVwZGF0 ZSB0aGlzIGlzc3VlIHRvIG1ha2UgaXQgY2xlYXIgd2hhdCBmdW5jdGlvbiB3YXMgYmVpbmcgZGlz Y3Vzc2VkLCBhbHNvIFN0ZXBoYW5lIHdpbGwgc2VuZCBvcHRpb25zIHRvIHRoZSB3b3JraW5nIGdy b3VwLSBsaXN0LiANCg0KIA0KDQpXZSBhcmUgc3BlY2lmaWNhbGx5IGxvb2tpbmcgZm9yIHBlb3Bs ZSB3aG8gb2ZmZXIgZXh0cmFuZXQgY29ubmVjdGlvbiBiZXR3ZWVuIHNpdGVzIGZyb20gZGlmZmVy ZW50IFZQTnMNCg0KIA0KDQogDQoNCj09IE90aGVyIElzc3VlcyA9PSAgICANCg0KIA0KDQogDQoN Ck1vZGVsaW5nIEN1c3RvbWVyIFNwZWNpZmljIEluZm8NCg0KIA0KDQotIENyZWF0ZSBhcHByb3Bp YXRlIGNvbnRhaW5lcnMgZm9yIFByb3ZpZGVyIEVkZ2UgYW5kIEN1c3RvbWVyIFNpdGUgcm91dGVy cw0KDQogDQoNCi0gVGhlIGN1cnJlbnQgIG1vZGVsIGNvbnRhaW5zIHJvdXRpbmcgcGFyYW1ldHJl cyB0aGF0IHJlZmVyIHRvIENFIGFuZCBQRSByZWxhdGlvbnNoaXBzDQoNCiANCg0KLSBHZW5lcmFs IGFncmVlbWVudCBpcyByb3V0aW5nIGluZm8gc2hvdWxkIGJlIHNwbGl0IGFuZCBjdXJyZW50IHBy b3Bvc2FsIHdpbGwgYmUgc2VudCB0byB0aGUgbGlzdCBmb3IgS2VuaWNoaSwgYW5kIHdvcmtpbmcg Z3JvdXBzLCByZXZpZXcuIA0KDQogDQoNCiANCg0KPT0gQ29uY2x1c2lvbnMgPT0NCg0KIA0KDQog DQoNCi0gQSBudW1iZXIgb2YgcmVzb2x1dGlvbnMgaGF2ZSBiZWVuIGFncmVlZCBhbmQgd2lsbCBi ZSB1cGRhdGVkIGluIHRoZSBJLUQNCg0KIA0KDQotIENoYWlycyB3b3VsZCBsaWtlIHRvIHNlZSBy ZXZpc2VkIEktRCBiYXNlZCBvbiB0aGUgYWdyZWVkIHBvaW50cw0KDQogDQoNCi0gUGxhbiB0byBo YXZlIGFub3RoZXIgaW50ZXJpbSBjYWxsIGF0IHRoZSBlbmQgb2YgSmFudWFyeSAoMjAxNikNCg0K IA0KDQotIENoYWlycyB0byBhZGQgbmV3IHRyYWNrZXIgaXRlbXMsIGluY2x1ZGluZyBzZWN1cml0 eSBmb3IgZnV0dXJlIGRpc2N1c3Npb24uIA0KDQogDQoNCiANCg0KIA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpMM3NtIG1haWxpbmcgbGlzdA0K DQpMM3NtQGlldGYub3JnIDxtYWlsdG86TDNzbUBpZXRmLm9yZz4gDQoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbSA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sM3NtPiANCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpMM3NtIG1haWxpbmcgbGlzdA0KDQpMM3NtQGlldGYub3JnIDxt YWlsdG86TDNzbUBpZXRmLm9yZz4gDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbDNzbSA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtPiAN Cg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCiANCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIEZyYW5jZSBUZWxlY29tIC0g T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpDQoNCiANCg0KVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcml6YXRpb24uDQoN CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIHNoYWxs IG5vdCBiZSBsaWFibGUgaWYgdGhpcyBtZXNzYWdlIHdhcyBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KIA0KDQogDQoNCiANCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQogDQoN CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaQ0KDQogDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3JpemF0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBzaGFsbCBub3QgYmUgbGlhYmxlIGlmIHRoaXMg bWVzc2FnZSB3YXMgbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3Uu DQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KTDNzbSBtYWlsaW5nIGxpc3QNCg0KTDNzbUBpZXRmLm9yZyA8bWFpbHRvOkwzc21AaWV0Zi5v cmc+IA0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20gPGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbT4gDQoNCiANCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KTDNzbSBtYWlsaW5nIGxp c3QNCg0KTDNzbUBpZXRmLm9yZyA8bWFpbHRvOkwzc21AaWV0Zi5vcmc+IA0KDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20gPGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbDNzbT4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpMM3NtIG1haWxpbmcgbGlzdA0KTDNzbUBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMM3NtIG1haWxpbmcgbGlzdA0KTDNzbUBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMM3NtIG1haWxp bmcgbGlzdA0KTDNzbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sM3NtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpMM3NtIG1haWxpbmcgbGlzdA0KTDNzbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQo= From nobody Wed Feb 24 19:50:51 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3931A8998 for ; Wed, 24 Feb 2016 19:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.048 X-Spam-Level: *** X-Spam-Status: No, score=3.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=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 GAJOPUiMn5eT for ; Wed, 24 Feb 2016 19:50:44 -0800 (PST) Received: from post-send.kddi.com (athena2.kddi.com [27.90.165.195]) by ietfa.amsl.com (Postfix) with ESMTP id 10BB41A8943 for ; Wed, 24 Feb 2016 19:50:42 -0800 (PST) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id 8A241E00B9; Thu, 25 Feb 2016 12:50:41 +0900 (JST) Received: from LTMC2145.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Thu, 25 Feb 2016 12:50:41 +0900 Received: from LTMC2145.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 59DE43A008B; Thu, 25 Feb 2016 12:50:41 +0900 (JST) Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2145.kddi.com (Postfix) with ESMTP id 4ED8E3A006D; Thu, 25 Feb 2016 12:50:41 +0900 (JST) Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1P3oerM001286; Thu, 25 Feb 2016 12:50:41 +0900 Received: from LTMC2152.kddi.com.mid_32232810 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1P3ebMd026702; Thu, 25 Feb 2016 12:40:37 +0900 X-SA-MID: 32232810 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Thu, 25 Feb 2016 12:40:36 +0900 From: "Ogaki, Kenichi" To: "'Aijun Wang'" <13301168517@189.cn>, , References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> <004101d16e97$e0692800$a13b7800$@kddi.com> <002d01d16e9f$88e66130$9ab32390$@cn> <006701d16ec0$1063fee0$312bfca0$@kddi.com> <004301d16ec8$270d9090$7528b1b0$@cn> <008401d16ede$20cee4c0$626cae40$@kddi.com> <004201d16f6f$22023cc0$6606b640$@cn> <015201d16f7c$3725b160$a5711420$@kddi.com> In-Reply-To: <015201d16f7c$3725b160$a5711420$@kddi.com> Date: Thu, 25 Feb 2016 12:40:36 +0900 Message-ID: <016201d16f7e$4a052a70$de0f7f50$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+JsdlYZ7cvi/Fz8JTONaqj4LvoQKs2aO/AYjUCCUDWny42AHbJwT5AVTH19oBa6ZKmwJ6yFzNARuYlCadZJzTAA== Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 03:50:48 -0000 Hi Aijun, I also proposed vpn-policy not only per sites, but also per = site-network-access as follows. https://mailarchive.ietf.org/arch/msg/l3sm/L5dzU-3BaGWRFJ9TBJjYREMAwUE In that case, it becomes too complex to control this under vpn-svc. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 25, 2016 12:26 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, If we configure the relationship between vpn-svc and sites as follows, = we should remove corresponding vpn-policy under sites to avoid the = inconsistency. In this case, when we create new sites, we must configure both sites and = vpn-svc, and this bothers our customers. But, the current model structure only have to configure sites. Then, I = prefer the current one. I don't object the sites list defined under vpn-svc as a *op-state*. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 10:52 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Based on our discussion, do you think the following proposal are = acceptable? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } =20 list sites{ leaf site-id leaf site-role leafref path "/l3vpn-svc/site-templates/site-template-id" = =20 } } list site-templates{ ...=20 } ... } -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Wednesday, February 24, 2016 4:34 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >Within the current Yang model, it is not loose coupled for the vpn and=20 >sites. Every site is associated with at least one vpn-policy entry. I wanted to mean by loose coupling that vpn and site should be = structurally at the same level. This means that a kind of graph = structure is better than a hierarchical structure. In a VPN service, it=E2=80=99s natural that a site must belong to at = least one vpn. >The reason that I prefer the "vpn-->site" structure to "site-->vpn"=20 >structure is that the majority of containers within lists "sites" are=20 >vpn-related, as you also confirmed this. >From the configuration viewpoint in the current model, the link = information between vpn and site can be configurable only in sites. = That's vpn-policy. This is reasonable to avoid the inconsistency in the case that both can = be configurable.=20 This information, which site belongs to which vpn, may be able to be = moved under vpn-svc as a list, but I don't think the necessity. It may = be useful to define the op-state under vpn-svc as discussed in issue#6. I agreed with the principle what you wrote, but I didn't carefully = discuss each container should be under vpn-svc or site. IMO, if any container is placed inappropriately, we should just move it = to the appropriate place. It's different problem from the model = structure discussion. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 2:57 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Within the current Yang model, it is not loose coupled for the vpn and = sites. Every site is associated with at least one vpn-policy entry.=20 The reason that I prefer the "vpn-->site" structure to "site-->vpn" = structure is that the majority of containers within lists "sites" are = vpn-related, as you also confirmed this. Then it is not enough in = current Yang model to correlate only the "vpn-policy" container to = different vpn id. And on the other way, we can also use the site-template to lessen the = burden of the customer configuration, as that done in current Yang = model. -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 12:59 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. > >[KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. >For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. >Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. >In that sense, I basically prefer the current model. >[Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. >There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement? If a physical customer site connects to two different vpns in this case, = the customer must input or update the information about the (physical) = site duplicately per vpn-svc. This may cause misconfiguration and bother = our customers. Another concern is the inconsistency with accounting/charging model, = when an operator charges the fee for physical access, it becomes = inconsistent with the charging model. When we does a traffic accounting = not only for logical access per vpn, but also for physical access, we = must always take care of the existence of different vpn-svc with the = same physical access in order to trigger a polling traffic counter of = the interface on PE. I understand it depends on each operator's service definition, vpn = specific or site specific, as Stephane wrote. To accommodate these different requirements, I think the loose coupled = model between the components, vpn and site, seems better. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 10:06 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Please see the reply inline. Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network = Research and Operation Support Department -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 8:11 AM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, See comments inline, please. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 18, 2016 1:12 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Stephane and Ogaki: =20 I suggested we put the "extranet-vpn-policy" under the list "vpn-svc" = directly, not in the container "vpn-policy" that is now under the list = "sites" in current model.=20 [KO]Like this? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } ... } ... } [Aijun Wang]: Yes. This can solve the initial scenario that proposed by Kenichi at the = beginning of our discussion. When the orchestrator receives the = information defined in "extranet-vpn-policy", it can allocate new = route-target for the involved VPNs and set them in the configuration = stanza of each router. =20 For the relationship of list "vpn-svc" and list "sites", I still suggest = we put the list "site" under the "vpn-svc", the reason for doing this is = as below: 1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. [KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. In that sense, I basically prefer the current model. [Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement?=20 2. The attributes of "sites", such as "maximum-routes", "security", = "service", "routing-protocols","site-netwok-accesses" etc. are all = service/site role related, that is to say, if the site role changed, all = of these attributed may be changed accordingly. [KO] I basically agree. The attributes tied to a whole vpn and globally = applied to all the sites under the vpn should be defined with the vpn = definition. 3.For container "vpn policy" that under list "sites" in current model, = there are two information defined, one is "filter" for prefix filtering, = another is "site-role". I suggest we split it, put the leaf "site-role" = under leaf "site-id" directly, and change the name of "vpn-policy" to = "site-prefix-policy".=20 =20 The final suggest structure of the L3VPN yang model will be look like = the bellow, I underline the changed positions from the current l3vpn = Yang Model =20 Container L3vpn-svc List vpn-svc Leaf vpn-id Leaf customer-name Leaf topology List extranet-vpn-policy Container cloud-access List multicast Leaf mpls List transport-contraints =20 List sites Leaf site-id Leaf site-role leaf apply-template ... ... ... ... Container managent Container site-prefix-policy Container maximum-routes Container security ... ... ... ... Site-network-access=20 =20 =20 Whether is it more reasonable?=20 =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute=20 Network Research and Operation Support Department =20 =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 18, 2016 9:08 AM To: l3sm@ietf.org Subject: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday = L3SM interim session =20 Hi Stephane and All, =20 As for issue #10 itself, the following solution can be acceptable for = us. =20 >One proposal could be to not call this VPN policy, but creating a >container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). =20 What model is in your mind? I can't see what ""extranet-vpn-policy" at = vpn" means. Like this? =20 ... 1 VPN1 VPN2 ... =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of stephane.litkowski@orange.com = =20 Sent: Monday, December 07, 2015 11:45 PM To: Ogaki, Kenichi; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi Kenichi, =20 Regarding your proposal of having a simple VPN policy in the vpn-svc = container, I do see an issue. One of the key point of the VPN policy is = to express the role of the site in the target VPN topology. If we do a vpn policy at VPN level, we cannot anymore describe site = roles in the target VPN which causes an issue. In an ideal world where all VPNs are any to any, the site role is always = the same and there is no issue, but let's think about someone trying to = use the vpn-policy (at vpn level) to connect to a Hub & Spoke VPN, how = do you deduce the roles of the sites ? =20 One proposal could be to not call this VPN policy, but creating a = container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). This means that the usage is really limited to "simple" = extranet-vpns and it does not replace nor compete with the VPN policy at = site level. =20 Could it be a good compromise ? =20 Stephane =20 =20 -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com = ] Sent: Saturday, December 05, 2015 06:23 To: LITKOWSKI Stephane SCE/OINIS; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear Stephane and All, =20 I don't say that sites *must* move under vpn-svc because I understand = stephane's use case. But we already have vpn-svc and some parameters under this are globally = applied to all the sites even in the current model. =20 It depends on operator's use case which is site-oriented or vpn-oriented = service. Our service is vpn-oriented, site has the native VPN. Then, I would just = like you to allow other global options to vpn-svc. =20 Thanks, Kenichi =20 -----Original Message----- From: stephane.litkowski@orange.com = = [mailto:stephane.litkowski@orange.com = ] Sent: Friday, December 04, 2015 8:17 PM To: Aijun Wang; 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi, =20 I'm against this proposal, as I do not want to create any dependency = between a particular VPN and a list of sites. A site can belong to multiple VPNs with any kind of topology, if we = attach the site to a single VPN, we come back to the notion of "native = VPN" we had at the beginning of the model which was hard to understand = and so was removed. =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Aijun Wang Sent: Friday, December 04, 2015 02:44 To: 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear all: =20 Can we put the list "sites" within the list "vpn-svc", and define the = general vpn policy for all sites that within the corresponding vpn = service instance? If doing so, some entries within the current list "sites" can also be = dragged out for general usual purposes, for example, "maximum-routes", = "security" etc. These parameters are often all same for every site = within one VPN service instance.=20 =20 If some sites have special requirements, we can achieve this by using = some special "site-vpn-policy" within the corresponding site definition. Is this more acceptable for customers? =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute Intelligent = Network Product Line =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Ogaki, Kenichi Sent: Friday, December 04, 2015 9:02 AM To: 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear All, =20 It was good having discussion. =20 As for issue#10, the objective and problem we discussed in the meeting = as follows. =20 The objective is to provide per-VPN extranet service which connects two = different VPNs (e.g. VPN1 and VPN2). It means that any sites in VPN1 can = access to any sites in VPN2. The problem is that the current model must update vpn-policy under all = the sites belong to these two VPNs in order to offer this service. = Especially when this model is used as a customer self-control API, it's = not good idea to require customers to update the information of all the = sites. (It's not abstracted way, a service model should provide what the = consumer wants, not how.) If a service or customer requires to control = per-site vpn-policy, that of current model should be used without = setting per-VPN vpn-polity. It depends on each operator's service. Stephane proposed to use apply-template, but it still cannot solve the = problem. When each VPN already has a large number of sites and want to = connect each other for the first time, both VPNs must update these sites = to apply apply-template on the current model. =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Qin Wu Sent: Friday, December 04, 2015 12:42 AM To: l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: [L3sm] L3SM interim meeting minutes on Thursday L3SM interim = session =20 Hi all: =20 =20 Below is the initial version of draft minutes for Thursday L3SM WG = interim session. =20 Thanks Dan to help take minutes. =20 Folks, please let us know if you have any correction. =20 =20 -Qin =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =20 L3SM Working Group Virtual Interim Meeting=20 =20 Thursday December 5th, 2015. 8am East Coast Time (New York) =20 =20 BLUE SHEET =20 =20 Name | Affiliation =20 ------------------------+----------------------------------------------- ------------------------+- =20 Adrian Farrel | Old Dog Consulting =20 Qin Wu | Huawei Technologies =20 Stephane Litkowski | Orange =20 Luis Tomotaki | Verizon =20 Daniel King | Old Dog Consulting =20 Susan Hares | Huawei Technologies =20 Scott Mansfield | Ericsson =20 Gu Rong | China Mobile=20 =20 Kenichi Ogaki | KDDI =20 Aijun Wang | China Telecom =20 Victor Santos | Ericsson =20 Ignas Bagdonas |=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 MINUTES =20 =20 * Meting logiistics = https://mailarchive.ietf.org/arch/msg/l3sm/SJub1aHVQGOQW6rWhthX0fB8Ac8 = = =20 =20 * Meeting materials = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/proceedings.html= = =20 =20 * Etherpad for minutes (this page) = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03 = =20 =20 * Jabber using l3sm@jabber.ietf.org =20 =20 * Blue sheet = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03-bluesheet = = =20 =20 =20 Agendaa =20 - Administrivia (Note Well, etc). a =20 - Introduction =20 - Open Issues for YANG Data Model for L3VPNservice delivery = (draft-ietf-l3sm-l3vpn-servicemodel) =20 o Open Issues discussion and resolution=E2=80=93 = http://trac.tools.ietf.org/wg/l3sm/trac/report/1 = =20 =20 =20 For a full list of issues and resolution proposals please see: = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/slides/slides-in= terim-2015-l3sm-1-2.pdf = =20 =20 =20 Issue#1: When customer-nat-address is used =20 Resolution #1: Leaf used when NAT is required to access cloud VPN and = customer wants to use its ownIP address. If provider provides the public = IP,no need to use the leaf =20 Status #1: Closed Pending I-D text review. =20 =20 Discussion on #1:=20 =20 =20 Aijun asks for more description in the YANG model itself =20 Stephane shows current model =20 Agreed OK =20 =20 Issue#2 : Identify l3vpn svc using id or name or both =20 Resolution #2: ID is a string, as per other properties in the model =20 Status #2: Closed =20 Discussion on #2:=20 =20 =20 Agreed OK =20 =20 Issue#3: M to N availability support =20 Resolution #3: Modeling sites using a list with a priority, so include = access list with a priority. =20 Status #3: =20 Discussion on #3:=20 =20 =20 Qin was asking that M to N availability is supported with access and = priority number.=20 =20 Stephane stated this is suppoted. This new proposal also supports = multiple sites, as a list. =20 Qin also asked if Group I-D was no longer needed, which it is not. Also = good solution supported by other operators. =20 Stephane asked if four priorities was enough, or if more were needed.=20 =20 =20 Re: Containers/Properties for Network Access Configuration - = Conclusions? =20 =20 o Location - Different site I-D? =20 o QoS Policy - Per network access link, or site information? Would QoS = (cost) be different per accesslink or site? Example of Primary and = Backup links given.=20 =20 o Bandwidth - Moved to access link group=20 =20 o Maximum Routes -=20 =20 Security, routing, and services are duplicated with inheritance =20 =20 =20 Issue#4: site-service-cloud access as grouping =20 Resolution #4 Already resilved as a separate grouping =20 Status #4: Closed =20 Discussion on #4:=20 =20 =20 Issue#5: Multicast support as raised by Eric Rosen =20 Resolution #5: : New "provider managed" property, and in Site Properties = "property-type" added =20 Status #5: Solution proposed.=20 =20 Discussion on #5:=20 =20 =20 Stephane will proviode new property proposals will be provided to Eric = for review.=20 =20 =20 Issue#6: Inventory operational state =20 Resolution #6: Include a new container for inventory state, or an RPC = call (sitting above the service orchestrator) to retrieve inventory = state.=20 =20 Status #6: Need to propose to the WG and agree solution. =20 Discussion on #6:=20 =20 =20 Luis asked would this info be collected from provision state? Stephane = suggested this would not be availible.=20 =20 Adrian observed that the code used to convert the model into a service = request may not utilise this inventory information capability. Sue = mentioned that others have mentioned by a vendor that it would be useful = to have the ability to configure inventory state. This should be = clarified by the operators.=20 =20 =20 Stephane to take proposals to list and ask anyone who is interested in = having the feature to suggest text. =20 =20 =20 Issue#7: Generic VAS - do we need to create a generic VAS container as = VAS are popular in L3VPNs? =20 Resolution #7: Separate from L3SM =20 Status #7: Closed =20 Discussion on #7:=20 =20 =20 Gu Rong highlighted Generic VAS model which was presented at IETF 94.=20 =20 =20 Issue#8: Who keeps site locationinformation? =20 Resolution #8: Text has been fixed =20 Status #8: Closed =20 Discussion on #8:=20 =20 =20 =20 Issue#9: Do we need to model transport constraints, such as: jitter, = disjoint, path diversity? =20 Resolution #9: Propose a "transport-constraint" group with = "constraint-type", "constraint-value" and "constraint-list" (composed of = type and values) =20 Status #9: Authors to propose the resolution in the I-D and provide to = the WG =20 Discussion on #9: =20 =20 =20 =20 Luis mentioned that they have multicast transport (multiple sites) and = bi-directional traffic applications (financial) that will require = transport constraints =20 =20 Duplicate transport constraints for unicast and multicast to give = options for separate configuration. =20 Keep single list entries for each src/dst pair even in the multicast = variant. =20 =20 DO we need to support multiple constraints or just have a single = composite (of multiple constraints), have the ability to specify a = constraint-list? =20 Aijun prfers list of constraints and meeting agrees this is OK =20 =20 What constraints to offer? =20 Latency =20 Path diversty =20 Site diversty =20 Jitter =20 Class of service was proposed but rejected =20 =20 Luis highlighted they have a current implementation that uses the = similar proposal. Luis also mentioned that site diversity might also be = required, would this be achievable =20 =20 =20 Issue#10: VPN "merging" =20 Resolution #10: =20 =20 Status #10: =20 Discussion on #10: =20 =20 =20 VPN is a per site property.=20 =20 - A site can belong tomultiple VPNs =20 - How to handle merging of two VPNs? =20 - Is this an issue the service model has to deal with? =20 =20 If VPN merging is required to be seamless, then this would be device = specific and not service model related. =20 =20 =20 "Merging" is a confusing term. The objective is NOT to merge VPN1 and = VPN2. =20 The objective is to provide an extranet so that some sites in VPN1 can = connect to some sites in VPN2 for some traffic. =20 This can be solved using a per-site property. =20 =20 Action: Need to update this issue to make it clear what function was = being discussed, also Stephane will send options to the working group- = list.=20 =20 We are specifically looking for people who offer extranet connection = between sites from different VPNs =20 =20 =3D=3D Other Issues =3D=3D =20 =20 =20 Modeling Customer Specific Info =20 - Create appropiate containers for Provider Edge and Customer Site = routers =20 - The current model contains routing parametres that refer to CE and PE = relationships =20 - General agreement is routing info should be split and current proposal = will be sent to the list for Kenichi, and working groups, review.=20 =20 =20 =3D=3D Conclusions =3D=3D =20 =20 - A number of resolutions have been agreed and will be updated in the = I-D =20 - Chairs would like to see revised I-D based on the agreed points =20 - Plan to have another interim call at the end of January (2016) =20 - Chairs to add new tracker items, including security for future = discussion.=20 =20 =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Wed Feb 24 19:56:44 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4E31A8778 for ; Wed, 24 Feb 2016 19:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 HdSsgzVJPKn2 for ; Wed, 24 Feb 2016 19:56:39 -0800 (PST) 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 574801A21A7 for ; Wed, 24 Feb 2016 19:56:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEY92245; Thu, 25 Feb 2016 03:56:36 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 03:56:35 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 11:56:31 +0800 From: Qin Wu To: "Ogaki, Kenichi" , "stephane.litkowski@orange.com" , "l3sm@ietf.org" Thread-Topic: [L3sm] Modeling a site with multiple subsites Thread-Index: AdFPnqCmtWfFPEtQT6m/5Yx5kcaoDABqSt8AABDyLYAAJeSogAar8U0AAKsvQfA= Date: Thu, 25 Feb 2016 03:56:31 +0000 Message-ID: References: <11137_1452868271_569902AF_11137_18933_1_9E32478DFA9976438E7A22F69B08FF921683F2D0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <009a01d1518a$dccd16e0$966744a0$@kddi.com> <28946_1453107612_569CA99C_28946_1310_1_9E32478DFA9976438E7A22F69B08FF921683F60F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <000001d15266$38428380$a8c78a80$@kddi.com> <002c01d16d15$fb50c390$f1f24ab0$@kddi.com> In-Reply-To: <002c01d16d15$fb50c390$f1f24ab0$@kddi.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.208] 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.0A020204.56CE7B74.00DF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0fc334dc862f576fa83551b6ce03c7ca Archived-At: Subject: Re: [L3sm] Modeling a site with multiple subsites X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 03:56:42 -0000 S2VuaWNoaToNCkNhbiB5b3UgY2xhcmlmeSBhIGxpdHRsZSBiaXQgdGhlIG9iamVjdGl2ZSBvZiB0 aGUgZm9sbG93aW5nIHByb3Bvc2FsPw0KU3VwcG9ydCBzdWJWUE4gY2FzZSBvciBtdWx0aXBsZSBu ZXR3b3JrIGFjY2Vzc2VzIHRoYXQgaXMgbm90IGZvciBtdWx0aWhvbWluZz8NCkkgYmVsaWV2ZSB0 aGlzIGlzc3VlIGlzIHNlcGFyYXRlZCBmcm9tIHdoYXQgd2UgZGlzY3Vzc2VkIGVhcmxpZXIgYWJv dXQgZXh0cmFuZXQgVlBOIHBvbGljeS4NCg0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+ yMs6IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gT2dha2ksIEtlbmlj aGkNCreiy83KsbzkOiAyMDE2xOoy1MIyMsjVIDEwOjA5DQrK1bz+yMs6IHN0ZXBoYW5lLmxpdGtv d3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQrW98ziOiBSZTogW0wzc21dIE1vZGVsaW5n IGEgc2l0ZSB3aXRoIG11bHRpcGxlIHN1YnNpdGVzDQoNCkhpIFN0ZXBoYW5lIGFuZCBBbGwsDQoN Cj4+SG93IHRvIHlvdSBkaWZmZXJlbnRpYXRlIG11bHRpaG9taW5nIGZyb20geW91ciBzdWJWUE4g Y2FzZT8gdGhleSBhcmUgDQo+PnR3byBkaWZmZXJlbnQNCj50aGluZ3MuDQoNCj5BcyBJIHdyb3Rl LCB3ZSBqdXN0IGhhdmUgdG8gKmR1cGxpY2F0ZSogdnBuLXBvbGljeSB1bmRlciANCj5zaXRlLW5l dHdvcmstYWNjZXNzLiBXaGVuIGFuIG9wZXJhdG9yJ3MgdXNlIGNhc2UgcmVxdWlyZXMgbXVsdGlW UE4sIA0KPnRoZW4gdnBuLXBvbGljeSBzaG91bGQgYmUgdW5kZXIgc2l0ZXMgYXMgdGhlIGN1cnJl bnQgbW9kZWwgZG9lcy4NCj5XaGVuIHRoZSBvdGhlciBvcGVyYXRvciByZXF1aXJlcyBzdWJWUE4s IHZwbi1wb2xpY3kgc2hvdWxkIGp1c3QgYmUgDQo+dW5kZXIgc2l0ZS0gbmV0d29yay1hY2Nlc3Mu IEl0J3Mgc3VmZmljaWVudCB0byB1c2UgdGhlc2UgdHdvIGNhc2VzIGV4Y2x1c2l2ZWx5Lg0KDQpI ZXJlIGlzIGEgbWluaW11bSBtb2RpZmljYXRpb24gcHJvcG9zYWwgdG8gdGhlIGN1cnJlbnQgbW9k ZWwgaW4gb3JkZXIgdG8gdXNlIHRoZXNlIHR3byBjYXNlcyBleGNsdXNpdmVseS4NCk9ubHkgaWYg YSB2cG4tcG9saWN5IGlzIG5vdCBkZWZpbmVkIGRpcmVjdGx5IHVuZGVyIHNpdGVzLCB3ZSBjYW4g ZGVmaW5lIGl0IHVuZGVyIHNpdGUtbmV0d29yay1hY2Nlc3MuDQpJZiBzb21ldGhpbmcgaXMgZ3Jh bW1hdGljYWxseSB3cm9uZyBpbiB0ZXJtcyBvZiBZQU5HIGFuZCBYUEFUSCBleHByZXNzaW9uLCBj b3VsZCBhbnlvbmUgY29ycmVjdCBtZT8NCg0KLi4uDQpjb250YWluZXIgc2l0ZS1uZXR3b3JrLWFj Y2Vzc2VzIHsNCiAgICBsaXN0IHNpdGUtbmV0d29yay1hY2Nlc3Mgew0KICAgICAgICB1c2VzIHNp dGUtdnBuLXBvbGljeSB7DQogICAgICAgICAgICByZWZpbmUgdnBuLXBvbGljeSB7DQogICAgICAg ICAgICAgICAgd2hlbiAibm90KC4uLy4uLy4uL3Zwbi1wb2xpY3kpIjsNCiAgICAgICAgICAgIH0N CiAgICAgICAgfQ0KICAgIC4uLg0KICAgIH0NCi4uLg0KfQ0KLi4uDQoNClRoYW5rcywNCktlbmlj aGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEwzc20gW21haWx0bzpsM3Nt LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBPZ2FraSwgS2VuaWNoaQ0KU2VudDogVHVl c2RheSwgSmFudWFyeSAxOSwgMjAxNiAxMjowNSBQTQ0KVG86IHN0ZXBoYW5lLmxpdGtvd3NraUBv cmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0wzc21dIE1vZGVsaW5nIGEg c2l0ZSB3aXRoIG11bHRpcGxlIHN1YnNpdGVzDQoNCkhpIFN0ZXBoYW5lLA0KDQo+V2UgY2Fubm90 IHVzZSBzaXRlLW5ldHdvcmstYWNjZXNzIHdoaWNoIGlzIHVzZWQgZm9yIG11bHRpaG9taW5nIG9u bHkuDQoNCldoeSBkbyB3ZSBoYXZlIHRvIHVzZSBzaXRlLW5ldHdvcmstYWNjZXNzIG9ubHkgZm9y IG11bHRpaG9taW5nPyBUaGlzIGlzIGludHVpdGl2ZWx5IG1hcHBlZCB0byBhIGxvZ2ljYWwgYWNj ZXNzIGFzIHlvdSB3cm90ZS4NCg0KDQo+SG93IHRvIHlvdSBkaWZmZXJlbnRpYXRlIG11bHRpaG9t aW5nIGZyb20geW91ciBzdWJWUE4gY2FzZT8gdGhleSBhcmUgdHdvIGRpZmZlcmVudCB0aGluZ3Mu DQoNCkFzIEkgd3JvdGUsIHdlIGp1c3QgaGF2ZSB0byAqZHVwbGljYXRlKiB2cG4tcG9saWN5IHVu ZGVyIHNpdGUtbmV0d29yay1hY2Nlc3MuIFdoZW4gYW4gb3BlcmF0b3IncyB1c2UgY2FzZSByZXF1 aXJlcyBtdWx0aVZQTiwgdGhlbiB2cG4tcG9saWN5IHNob3VsZCBiZSB1bmRlciBzaXRlcyBhcyB0 aGUgY3VycmVudCBtb2RlbCBkb2VzLg0KV2hlbiB0aGUgb3RoZXIgb3BlcmF0b3IgcmVxdWlyZXMg c3ViVlBOLCB2cG4tcG9saWN5IHNob3VsZCBqdXN0IGJlIHVuZGVyIHNpdGUtbmV0d29yay1hY2Nl c3MuIEl0J3Mgc3VmZmljaWVudCB0byB1c2UgdGhlc2UgdHdvIGNhc2VzIGV4Y2x1c2l2ZWx5Lg0K DQoNCj5Db3VsZCB5b3UgcHJvdmlkZSBtb3JlIHRlY2huaWNhbCBkZXRhaWwgc28gSSB3aWxsIGJl IGFibGUgdG8gdW5kZXJzdGFuZCB3aGF0IGV4YWN0bHkgeW91IGFyZSB0cnlpbmcgdG8gYWNoaWV2 ZSA/DQoNCk91ciBleGlzdGluZyBjb21tZXJjaWFsIHNlcnZpY2UgYWxsb3dzIHRoZSAqbG9naWNh bGx5KiBmb2xsb3dpbmcgZGlhZ3JhbS4NClBFMSwgUEUyIGFuZCBQRTMgY2FuIGJlIFZSRnMgaW5z aWRlIGEgc2luZ2xlIHBoeXNpY2FsIFBFLCBvciBtYXkgYmUgcGh5c2ljYWxseSBzZXBhcmF0ZSBQ RXMuIFNhbWUgYXMgQ0VzLiBMMlNXIGNhbiBiZSBRaW5RIHN1Yi1pbnRlcmZhY2VzIG9uIGEgc2lu Z2xlIHBoeXNpY2FsIFBFIGRlcGVuZGluZyBvbiB0aGUgYWJvdmUgY2FzZS4NCg0KVGhlbiwgd2Ug bWF5IG1hcCBlYWNoIGVsZW1lbnQgbGlrZSB0aGlzLg0KDQpzaXRlczogQSBjdXN0b21lciBwcmVt aXNlcyBjb25uZWN0ZWQgdmlhIFFpblEgKHN0YWcgMTAwKQ0Kc3ViLXNpdGVzOiBBIGN1c3RvbWVy IHByZW1pc2VzJyBsYXllciAyIHNlZ21lbnQgc2VwYXJhdGVkIGJ5IC4xUSAoY3RhZyAxMCBvciAy MCksIGEgY3RhZyBzZWdtZW50IGNhbiBpbmNsdWRlIG11bHRpcGxlIGxvZ2ljYWwgYWNjZXNzZXMg d2l0aCBiZ3AgcGVlciBwZXIgbG9naWNhbCBhY2Nlc3MuIEZvciBleGFtcGxlLCBQRTEgaGFzIGEg YmdwIHBlZXIgd2l0aCBDRTEsIGFuZCBQRTIgaGFzIGEgZGlmZmVyZW50IGJncCBwZWVyIHdpdGgg Q0UyLg0KDQpJbiB0aGlzIGNhc2UsIHdoZW4gVlBOIFggb25seSB0YWxrcyB0byBMQU4gWCwgd2Ug bmVlZCBzdWJWUE4gaW5zaWRlIHN1Yi1zaXRlcy4gQnV0LCB3ZSBjYW4gZGVhbCB3aXRoIGEgc3Vi LXNpdGVzIGFzIGEgc2l0ZXMgZm9yIHRoZSBzaW1wbGljaXR5IHRvIG1pbmltYWxseSBleHRlbmQg dGhlIGN1cnJlbnQgbW9kZWwuIEV2ZW4gc28sIHdlIHN0aWxsIG5lZWQgdnBuLXBvbGljeSBwZXIg c2l0ZS1uZXR3b3JrLWFjY2Vzcy4NCg0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQp8 ICAgICAgICAvLS0tXCBjdGFnIDEwICAgICAgICB8ICAgICAgICB8ICAgICAgICBjdGFnIDEwIC8t LS1cICAgICAgICAgfA0KfCBWUE4gQS0rIFBFMSArLS0tLS0tLS0rICAgICAgfCAgICAgICAgfCAg ICAgICstLS0tLS0tLSsgQ0UxICstTEFOIEEgIHwNCnwgICAgICAgIFwtLS0vICAgICAgICAgfCAg ICAgIHwgICAgICAgIHwgICAgICB8ICAgICAgICAgXC0tLS8gICAgICAgICB8DQp8ICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICB8ICAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgfA0KfCAgICAgICAgLy0tLVxjdGFnIDEwKy0rLS0tLSsgfHN0YWcgMTAwfCArLS0tLSstK2N0 YWcgMTAvLS0tXCAgICAgICAgIHwNCnwgVlBOIEItKyBQRTIgKy0tLS0tLSsgTDJTVyArLSstLS0t LS0tLSstKyBMMlNXICstLS0tLS0rIENFMiArLUxBTiBCICB8DQp8ICAgICAgICBcLS0tLyAgICAg ICArLSstLS0tKyB8ICAgICAgICB8ICstLS0tKy0rICAgICAgIFwtLS0vICAgICAgICAgfA0KfCAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAgICAgICAgfCAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgIHwNCnwgICAgICAgIC8tLS1cY3RhZyAyMCAgfCAgICAgIHwgICAgICAgIHwgICAg ICB8IGN0YWcgMjAgLy0tLVwgICAgICAgICB8DQp8IFZQTiBDLSsgUEUzICstLS0tLS0tLSsgICAg ICB8ICAgICAgICB8ICAgICAgKy0tLS0tLS0tKyBDRTMgKy1MQU4gQyAgfA0KfCAgICAgICAgXC0t LS8gICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICBcLS0tLyAgICAgICAg IHwNCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgQ2VudHJhbCBPZmZp Y2UgICAgICAgICAgICAgICAgICAgICAgICBDdXN0b21lciBQcmVtaXNlcw0KDQpBbGwgdGhlIGJl c3QsDQpLZW5pY2hpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMM3NtIFtt YWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygc3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb20NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxOCwgMjAxNiA2OjAwIFBNDQpU bzogT2dha2ksIEtlbmljaGk7IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTDNzbV0gTW9k ZWxpbmcgYSBzaXRlIHdpdGggbXVsdGlwbGUgc3Vic2l0ZXMNCg0KSGksDQoNCldlIGNhbm5vdCB1 c2Ugc2l0ZS1uZXR3b3JrLWFjY2VzcyB3aGljaCBpcyB1c2VkIGZvciBtdWx0aWhvbWluZyBvbmx5 Lg0KSG93IHRvIHlvdSBkaWZmZXJlbnRpYXRlIG11bHRpaG9taW5nIGZyb20geW91ciBzdWJWUE4g Y2FzZSA/IHRoZXkgYXJlIHR3byBkaWZmZXJlbnQgdGhpbmdzLg0KU28gSSdtIGNvbXBsZXRlbHkg YWdhaW5zdCB1c2luZyBzaXRlLW5ldHdvcmstYWNjZXNzZXMgYXMgYSBzdWJWUE4gY2FuIGJlIGFs c28gbXVsdGlob21lZCAuLi4NCg0KPiBGWUksIG91ciBjb21tZXJjaWFsIHNlcnZpY2UgaG9uZXN0 bHkgaGFzIGEgc2ltaWxhciBlbGVtZW50IGFzIHN1Yi1zaXRlcywgY29ycmVzcG9uZGluZyB0byB2 bGFuLCBidXQgd2Ugc3RpbGwgYWxsb3dzIG11bHRpcGxlIHZwbnMgYW5kIGJncCBwZWVycywgZWFj aCBkaWZmZXJlbnQgdnBuIGFjY2VzcyBwZXIgcGVlciwgd2l0aGluIGEgc2luZ2xlIHZsYW4uDQpD b3VsZCB5b3UgcHJvdmlkZSBtb3JlIHRlY2huaWNhbCBkZXRhaWwgc28gSSB3aWxsIGJlIGFibGUg dG8gdW5kZXJzdGFuZCB3aGF0IGV4YWN0bHkgeW91IGFyZSB0cnlpbmcgdG8gYWNoaWV2ZSA/DQoN CkJlc3QgUmVnYXJkcywNCg0KU3RlcGhhbmUNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogT2dha2ksIEtlbmljaGkgW21haWx0bzprZS1vb2dha2lAa2RkaS5jb21dDQpTZW50 OiBNb25kYXksIEphbnVhcnkgMTgsIDIwMTYgMDE6NTUNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUg U0NFL09JTklTOyBsM3NtQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0wzc21dIE1vZGVsaW5nIGEg c2l0ZSB3aXRoIG11bHRpcGxlIHN1YnNpdGVzDQoNCkhpIFN0ZXBoYW5lLA0KDQo+U2luZ2xlICJw aHlzaWNhbCIgYWNjZXNzIGJldHdlZW4gU1AgYW5kIGN1c3RvbWVyLCBidXQgbXVsdGlwbGUgc3Vi LWFjY2Vzc2VzIG9uIHRvcCAoVkxBTiwgUFBQIHNlc3Npb25zLCBvciB3aGF0ZXZlciAuLi4pLCBl YWNoIG9uZSBwb2ludGluZyB0byBhIHNwZWNpZmljIFZQTi4NCg0KQXMgeW91IHdyb3RlIGFib3Zl IGluIHRoZSBzY2VuYXJpbyBhKSBhbmQgYiksIHZwbi1wb2xpY3kgb25seSBoYXZlIHRvIGJlIGNv bnRyb2xsZWQgcGVyIGxvZ2ljYWwgYWNjZXNzLCBlcXVpdmFsZW50IHRvIHRoZSBzaXRlLW5ldHdv cmstYWNjZXNzIGluIHRoZSBjdXJyZW50IG1vZGVsLiBUbyBzb2x2ZSB0aGUgaXNzdWUgYXMgc2lt cGxlIGFzIHBvc3NpYmxlLCBpdCdzIHN1ZmZpY2llbnQgdG8gZHVwbGljYXRlIHZwbi1wb2xpY3kg dW5kZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzcy4NCkluIHRoZXNlIGNhc2VzLCBhIGNvbXBsZXRlbHkg ZGlmZmVyZW50IGNvbmNlcHR1YWwgZWxlbWVudCwgc3ViLXNpdGVzLCBpcyBub3QgcmVxdWlyZWQu IFRoaXMgbXVzdCBicmluZyBhIGNvbXBsZXhpdHksIGFuZCBzb21ldGltZXMgaGFyZCB0byBiZSB1 bmRlcnN0b29kLCBkZXBlbmRpbmcgb24gb3BlcmF0b3IncyB1c2VjYXNlLiANCkFsdGhvdWdoIHdl IHNob3VsZG4ndCBkaXNjdXNzIHRoZSBkZXZpY2UgbW9kZWxsaW5nLCB0aGUgZ3JhbnVsYXJpdHkg b2Ygc3ViLXNpdGVzIGNvcnJlc3BvbmRzIHRvIGEgVlJGJ3Mgb25lIGZyb20gdGhlIHZpZXdwb2lu dCBvZiB2cG4tcG9saWN5LiBJbiB0aGlzIGNhc2UsIG5vYm9keSBpbnR1aXRpdmVseSBpbWFnaW5l cyAoc3ViLSlzaXRlcyBmcm9tIFZSRiwgYmVjYXVzZSBpdCdzIGNvbW1vbmx5IGluIGEgc2luZ2xl IHBoeXNpY2FsIGJveC4NCg0KRllJLCBvdXIgY29tbWVyY2lhbCBzZXJ2aWNlIGhvbmVzdGx5IGhh cyBhIHNpbWlsYXIgZWxlbWVudCBhcyBzdWItc2l0ZXMsIGNvcnJlc3BvbmRpbmcgdG8gdmxhbiwg YnV0IHdlIHN0aWxsIGFsbG93cyBtdWx0aXBsZSB2cG5zIGFuZCBiZ3AgcGVlcnMsIGVhY2ggZGlm ZmVyZW50IHZwbiBhY2Nlc3MgcGVyIHBlZXIsIHdpdGhpbiBhIHNpbmdsZSB2bGFuLg0KDQpBbGwg dGhlIGJlc3QsDQpLZW5pY2hpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBM M3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygc3RlcGhhbmUu bGl0a293c2tpQG9yYW5nZS5jb20NClNlbnQ6IEZyaWRheSwgSmFudWFyeSAxNSwgMjAxNiAxMToz MSBQTQ0KVG86IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFtMM3NtXSBNb2RlbGluZyBhIHNpdGUg d2l0aCBtdWx0aXBsZSBzdWJzaXRlcw0KDQpbQ3JlYXRpbmcgYW5vdGhlciB0b3BpYyBmb3IgYmV0 dGVyIGZvbGxvd3VwXQ0KDQogDQoNClRvZGF5IHRoZSBtb2RlbCBoYXMgdGhlIGFiaWxpdHkgdG8g Y3JlYXRlIHNpdGVzLCBhIHNpdGUgY2FuIGJlIG11bHRpaG9tZWQgdG8gdGhlIG5ldHdvcmsgdGhh bmtzIHRvIHRoZSBzaXRlLW5ldHdvcmstYWNjZXNzIHN1Yi10cmVlLg0KDQogDQoNCk5vdyB0aGUg cXVlc3Rpb24gaXMgaG93IHRvIHdlIG1vZGVsIHN1Y2ggc2NlbmFyaW9zIDoNCg0KIA0KDQphKSAg ICAgICJTVUJWUE4gY2FzZSIgOiBTaW5nbGUgInBoeXNpY2FsIiBhY2Nlc3MgYmV0d2VlbiBTUCBh bmQgY3VzdG9tZXIsIGJ1dCBtdWx0aXBsZSBzdWItYWNjZXNzZXMgb24gdG9wIChWTEFOLCBQUFAg c2Vzc2lvbnMsIG9yIHdoYXRldmVyIC4pLCBlYWNoIG9uZSBwb2ludGluZyB0byBhIHNwZWNpZmlj IFZQTi4gSXQgaXMgZXhwZWN0ZWQgZm9yIHRoZSBjdXN0b21lciB0byBlbnN1cmUgZmxvdyBzZXBh cmF0aW9uIChWUkYgbGl0ZSwgVkxBTnMgLikuIEl0J3MgdHlwaWNhbGx5IGEgYmlnIGNvbXBhbnkg d2l0aCBhIEh1YiBzaXRlIHVzZWQgd2hlcmUgYWZmaWxpYXRlcyBoYXZlIGRlZGljYXRlZCByZXNv dXJjZXMgaW4gdGhlIEh1YiBzaXRlLCBhbmQgYWZmaWxpYXRlcyBtdXN0IG5vdCB0YWxrIHRvIGVh Y2ggb3RoZXIgb3IgZXZlbiBzaGFyZSByZXNvdXJjZXMuIE5vdGUgdGhhdCBJIHB1dHRlZCAicGh5 c2ljYWwiIGJldHdlZW4gcXVvdGVzIGJlY2F1c2UgaXQgY2FuIGJlIGEgbmVzdGVkIGxvZ2ljYWwg YWNjZXNzZXMgLg0KDQogDQoNCiANCg0KYikgICAgICAiSU5URVItQVMgb3B0aW9uIEEgbGlrZSAi IGNhc2UgOiB0aGlzIGlzIHRoZSBiYWNrIHRvIGJhY2sgVlJGIGNhc2UsIGFzIHByZXZpb3VzbHkg c2luZ2xlICJwaHlzaWNhbCIgYWNjZXNzIGFuZCBtdWx0aXBsZSBsb2dpY2FsIGFjY2Vzc2VzIG9u IHRvcCBlYWNoIG9uZSBwb2ludGluZyB0byBhIHNlcGFyYXRlIFZQTi4gSSBwdXR0ZWQgaW50ZXJB UywgYnV0IHRoaXMgY2FuIGJlICJpbnRyYS1BUyIgd2l0aCBpQkdQIGJhY2sgdG8gYmFjayBWUkZz IGFsc28gKGludGVybmFsIERDIGZvciBleGFtcGxlKQ0KDQogDQoNCmMpICAgICAgIFdoYXQgYWJv dXQgb3B0aW9uIEIgPyBEbyB3ZSBjb25zaWRlciBvcHRpb24gQiBhcyBhIHNlcnZpY2UgPyBJIHdv dWxkIG5vdCBiZSBpbiBmYXZvciBvZiB0aGF0LiBPcHRpb24gQiBzZXR1cHMgYXJlIHJlYWxseSBw YXJ0aWN1bGFyIGluIHRlcm0gb2YgZGVzaWduLCBzZWN1cml0eSAuICBTbyBJIHdvdWxkIGxpa2Ug dG8gaGF2ZSBvcHRpb24gQiBvdXQgb2Ygc2NvcGUuDQoNCiANCg0KIA0KDQpFdmVuIGlmIGEpIGFu ZCBiKSBhcmUgc2VwYXJhdGVkIHVzZSBjYXNlcyBmcm9tIGEgc2VydmljZSBwb2ludCBvZiB2aWV3 LCB0aGVzZSBhcmUgc2ltaWxhciBpbiB0ZXJtIG9mIG1vZGVsaW5nLg0KDQogDQoNClRvZGF5IHdl IGNhbiBtb2RlbCBpdCBoYXMgYSBjb2xsZWN0aW9uIG9mIHNlcGFyYXRlZCBzaXRlcyB3aXRob3V0 IGFueSByZWxhdGlvbnNoaXAgYmV0d2VlbiBlYWNoIG90aGVyLiBUaGUgb3RoZXIgcG9pbnQgaXMg dGhhdCB3ZSBjYW5ub3QgZXhwcmVzcyBhbnkgIHByb3BlcnR5IG9mIHRoZSAicGh5c2ljYWwiIGF0 dGFjaG1lbnQgYnV0IHRoZXJlIG1heSBmZXcgKGVuY3J5cHRpb24gPykuIFdlIGNhbiBrZWVwIHRo ZSBtb2RlbCBhcyBpdCBpcyB3aXRoIHRoaXMgbGltaXRhdGlvbiBvciB3ZSBjYW4gY3JlYXRlIHNp dGUgYW5kIHN1Yi1zaXRlIGhpZXJhcmNoeSB3aGljaCBhcyBJIGFscmVhZHkgc2FpZCBtYXkgY29t cGxleGlmeSB0aGUgcmVhZGluZyBhbmQgdXNhYmlsaXR5IChJTU8pLg0KDQpJdCBtYXkgbG9vayBs aWtlIHRoaXMgOg0KDQogDQoNCqGkICAgICAgICAgU2l0ZXMNCg0KbyAgIFNpdGUtb25seS1wYXJh bWV0ZXJzIDoNCg0KoewgIExvY2F0aW9uDQoNCqHsICBEaXZlcnNpdHkNCg0KoewgIG1hbmFnZW1l bnQNCg0KoewgIFNlY3VyaXR5DQoNCm8gICBTcGVjaWZpYy1wYXJhbWV0ZXJzIDogPC0gdG8gYmUg dXNlZCBvbmx5IGlmIHRoZXJlIGlzIG5vIHN1YnNpdGUuDQoNCqHsICBWcG4tcG9saWN5DQoNCqHs ICBTZXJ2aWNlcw0KDQqh7CAgUm91dGluZy1wcm90b2NvbHMNCg0KoewgIFNpdGUtbmV0d29yay1h Y2Nlc3Nlcw0KDQqhpCAgICAgICAgIC4uDQoNCm8gICBTdWItc2l0ZXMgOiA8LSB0byBiZSB1c2Vk IGluIGNhc2Ugb2Ygc3ViIHNpdGVzIHByZXNlbnQNCg0KoewgIFNwZWNpZmljLXBhcmFtZXRlcnMg Og0KDQqhpCAgICAgICAgIFZwbi1wb2xpY3kNCg0KoaQgICAgICAgICBTZXJ2aWNlcw0KDQqhpCAg ICAgICAgIFJvdXRpbmctcHJvdG9jb2xzDQoNCqGkICAgICAgICAgU2l0ZS1uZXR3b3JrLWFjY2Vz c2VzDQoNCm8gICAuDQoNCiANCg0KSSdtIGFsc28gd29uZGVyaW5nIGlmIGJlYXJlciBwYXJhbWV0 ZXJzIG11c3QgYWxzbyBiZSB0YWtlbiBvdXQgaW4gdGhpcyBjYXNlIGFuZCBwdXR0ZWQgaW4gdGhl IHNpdGUtb25seS1wYXJhbWV0ZXJzLiANCg0KVGhlIGhpZXJhcmNoeSBiZWNvbWVzIHJlYWxseSBj b21wbGV4IGhlcmUgYW5kIEkgd291bGQgbGlrZSB0byBrZWVwIGl0IGFzIHNpbXBsZSBhcyBwb3Nz aWJsZS4NCg0KIA0KDQogDQoNCldvdWxkIGJlIGdvb2QgdG8gaGF2ZSBtdWx0aXBsZSBmZWVkYmFj a3MgZnJvbSB0aGUgV0cgdG8gc2VlIHdoZXJlIHRoZSBjb25zZW5zdXMgaXMuDQoNCiANCg0KIA0K DQpPcmFuZ2UgbG9nbyA8aHR0cDovL3d3dy5vcmFuZ2UuY29tLz4gDQoNCiANCg0KU3RlcGhhbmUg TGl0a293c2tpDQpOZXR3b3JrIEFyY2hpdGVjdA0KT3JhbmdlL1NDRS9FUVVBTlQvT0lOSVMvTkVU DQoNCk9yYW5nZSBFeHBlcnQgRnV0dXJlIE5ldHdvcmtzDQoNCnBob25lOiArMzMgMiAyMyAyOCA0 OSA4MyA8aHR0cHM6Ly9tb25zaS5zc28uZnJhbmNldGVsZWNvbS5mci9pbmRleC5hc3A/dGFyZ2V0 PWh0dHAlM0ElMkYlMkZjbGljdm9pY2Uuc3NvLmZyYW5jZXRlbGVjb20uZnIlMkZDbGljdm9pY2VW MiUyRlRvb2xCYXIuZG8lM0ZhY3Rpb24lM0RkZWZhdWx0JTI2cm9vdHNlcnZpY2UlM0RTSUdOQVRV UkUlMjZ0byUzRCszMyUyMDIlMjAyMyUyMDI4JTIwNDklMjA4MyUyMD4NCm1vYmlsZTogKzMzIDYg MzcgODYgOTcgNTIgPGh0dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20uZnIvaW5kZXguYXNw P3RhcmdldD1odHRwJTNBJTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxlY29tLmZyJTJGQ2xp Y3ZvaWNlVjIlMkZUb29sQmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJvb3RzZXJ2aWNlJTNE U0lHTkFUVVJFJTI2dG8lM0QrMzMlMjA2JTIwMzclMjA4NiUyMDk3JTIwNTIlMjA+DQpzdGVwaGFu ZS5saXRrb3dza2lAb3JhbmdlLmNvbSA8bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2Uu Y29tPiAgDQoNCiANCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpMM3NtIG1haWxpbmcgbGlzdA0KTDNzbUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMM3NtIG1haWxpbmcgbGlzdA0K TDNzbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3Nt DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMM3Nt IG1haWxpbmcgbGlzdA0KTDNzbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sM3NtDQo= From nobody Wed Feb 24 20:37:10 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93ED91B30BF for ; Wed, 24 Feb 2016 20:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.048 X-Spam-Level: *** X-Spam-Status: No, score=3.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=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 whyj0EynFcC5 for ; Wed, 24 Feb 2016 20:37:02 -0800 (PST) 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 D0A3A1B2A5F for ; Wed, 24 Feb 2016 20:37:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEY94578; Thu, 25 Feb 2016 04:36:58 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 04:36:55 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 12:36:49 +0800 From: Qin Wu To: Aijun Wang <13301168517@189.cn>, "'Ogaki, Kenichi'" , "stephane.litkowski@orange.com" , "l3sm@ietf.org" Thread-Topic: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session Thread-Index: AdFUzU8XUm4agADpQBu6GQYzpCj8XwVLtpZwARYqJIAAAejoAAAIIwmAAAIEnwAABX+QAAAkPvQAABRtUWAAAKws8AABXTxw Date: Thu, 25 Feb 2016 04:36:48 +0000 Message-ID: References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> <004101d16e97$e0692800$a13b7800$@kddi.com> <002d01d16e9f$88e66130$9ab32390$@cn> <006701d16ec0$1063fee0$312bfca0$@kddi.com> <004301d16ec8$270d9090$7528b1b0$@cn> <008401d16ede$20cee4c0$626cae40$@kddi.com> <004201d16f6f$22023cc0$6606b640$@cn> <008101d16f80$b7dbafe0$27930fa0$@cn> In-Reply-To: <008101d16f80$b7dbafe0$27930fa0$@cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.208] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56CE84EB.0153, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f9d4b28207e13f101c0388bd3ec1fd45 Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 04:37:08 -0000 V2hlbiBvbmUgc2l0ZSBiZWxvbmdzIHRvIGRpZmZlcmVudCBWUE5zIGFuZCBoYXZlIG11bHRpcGxl IHJvbGVzLCBjYW4geW91IGRlc2NyaWJlIHRoZXNlIHJvbGVzIGluIHRoZSBzYW1lIHNlcnZpY2Ug bW9kZWwgd2l0aCB5b3VyIHByb3Bvc2FsPw0KDQotUWluDQotLS0tLemCruS7tuWOn+S7ti0tLS0t DQrlj5Hku7bkuro6IEFpanVuIFdhbmcgW21haWx0bzoxMzMwMTE2ODUxN0AxODkuY25dIA0K5Y+R 6YCB5pe26Ze0OiAyMDE25bm0MuaciDI15pelIDExOjU4DQrmlLbku7bkuro6IFFpbiBXdTsgJ09n YWtpLCBLZW5pY2hpJzsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5v cmcNCuS4u+mimDogUkU6IFtMM3NtXSBJc3N1ZSAjMTAgUkU6IEwzU00gaW50ZXJpbSBtZWV0aW5n IG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KSGksIFFpbjoNCg0K TWF5YmUgSSBkbyBub3QgZGVzY3JpYmUgdGhlIHN0cnVjdHVyZSBjbGVhcmx5LiBJIHB1dCB0aGUg bGVhZiAic2l0ZS1yb2xlIiB1bmRlciBsaXN0cyAic2l0ZXMiLCB3aGljaCBpcyBsb2NhdGVkIHdp dGhpbiB0aGUgbGlzdCB2cG4tc3ZjLiBUaGVuIGluIGRpZmZlcmVudCB2cG4sIHRoZSBzaXRlLXJv bGUgY2FuIGJlIGRpZmZlcmVudC4NCg0KQmVzdCBSZWdhcmRzLg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogUWluIFd1IFttYWlsdG86YmlsbC53dUBodWF3ZWkuY29tXQ0KU2Vu dDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI1LCAyMDE2IDExOjQ4IEFNDQpUbzogQWlqdW4gV2FuZzsg J09nYWtpLCBLZW5pY2hpJzsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0 Zi5vcmcNClN1YmplY3Q6IFJFOiBbTDNzbV0gSXNzdWUgIzEwIFJFOiBMM1NNIGludGVyaW0gbWVl dGluZyBtaW51dGVzIG9uIFRodXJzZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCkFpanVuOg0K SXQgbG9va3MgbGlrZSB5b3UgcHJvcG9zZSB0byByZWxvY2F0ZSBzb21lIHBhcmFtZXRlcnMgaW4g dGhlIG1vZGVsIHN0cnVjdHVyZS4NCkJ1dCB3aXRoIHlvdXIgcHJvcG9zYWwsIGl0IGlzIGhhcmQg dG8gZGVzY3JpYmUgb25lIHNpdGUgcGxheWluZyBkaWZmZXJlbnQgcm9sZSBpbiBkaWZmZXJlbnQg VlBOIHdoZW4gb25lIHNpdGUgYmVsb25ncyB0byBtdWx0aXBsZSBWUE5zLg0KV2l0aCBWUE4tcG9s aWN5IHVuZGVyIHNpdGUgcHJvcG9zZWQgaW4gdGhlIGN1cnJlbnQgbW9kZWwsIHlvdSBjYW4gZWFz aWx5IGRlc2NyaWJlIG9uZSBzaXRlIHdpdGggZGlmZmVyZW50IHJvbGUgaW4gZWFjaCBWUE4gYXMg Zm9sbG93czoNCiINCiAgICBjb250YWluZXIgbDN2cG4tc3ZjIHsNCiAgICAgICAgbGlzdCB2cG4t c3ZjIHsNCiAgICAgICAgICAgIGtleSB2cG4taWQ7DQoNCiAgICAgICAgICAgIGxlYWYgdnBuLWlk IHsNCiAgICAgICAgICAgICAgICDigKYNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIC4uLg0K ICAgICAgICANCiAgICAgICAgICAgIGxpc3Qgc2l0ZXN7DQogICAgICAgICAgICAgIGxlYWYgc2l0 ZS1pZA0KICAgICAgICAgIGNvbnRhaW5lciB2cG4tcG9saWN5IHsNCiAgICAgICAgICAgIGxpc3Qg ZW50cmllcyB7DQogICAgICAgICAgICAgICAga2V5IGlkOw0KICAgICAgICAgICAgICAgIGxlYWYg aWQgew0KICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSBzdmMtaWQ7DQogICAgICAgICAgICAg ICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICJVbmlxdWUg aWRlbnRpZmllciBmb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHBvbGljeSBlbnRy eS4iOw0KICAgICAgICAgICAgICAgIH0NCmNvbnRhaW5lciB2cG4gew0KICAgICAgICAgICAgICAg ICAgICBsZWFmIHZwbiB7DQogICAgICAgICAgICAgICAgICAgICAgICB0eXBlIGxlYWZyZWYgew0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhdGggIi9sM3Zwbi1zdmMvdnBuLXN2Yy92cG4t aWQiOw0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAg bWFuZGF0b3J5IHRydWU7DQogICAgICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICJSZWZlcmVuY2UgdG8gYW4gSVBWUE4uIjsNCiAgICAgICAg ICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICBsZWFmIHNpdGUtcm9sZSB7DQogICAg ICAgICAgICAgICAgICAgICAgICB0eXBlIGlkZW50aXR5cmVmIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBiYXNlIHNpdGUtcm9sZTsNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAg ICAgICAgICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0KICAgICAgICAgICAgICAgICAg ICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAiUm9sZSBvZiB0aGUg c2l0ZSBpbiB0aGUgSVBWUE4uIjsNCiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAg ICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICAgICAgIkxpc3Qgb2YgVlBOcyB0 aGUgTEFOIGlzIGFzc29jaWF0ZWQgdG8uIjsNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAg ICAgIH0NCiAgICAgICAgfQ0KIg0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu2 5Lq6OiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggQWlqdW4gV2Fu Zw0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0MuaciDI15pelIDk6NTINCuaUtuS7tuS6ujogJ09nYWtp LCBLZW5pY2hpJzsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5vcmcN CuS4u+mimDogUmU6IFtMM3NtXSBJc3N1ZSAjMTAgUkU6IEwzU00gaW50ZXJpbSBtZWV0aW5nIG1p bnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KSGksIE9nYWtpOg0KDQpC YXNlZCBvbiBvdXIgZGlzY3Vzc2lvbiwgZG8geW91IHRoaW5rIHRoZSBmb2xsb3dpbmcgcHJvcG9z YWwgYXJlIGFjY2VwdGFibGU/DQoNCiAgICBjb250YWluZXIgbDN2cG4tc3ZjIHsNCiAgICAgICAg bGlzdCB2cG4tc3ZjIHsNCiAgICAgICAgICAgIGtleSB2cG4taWQ7DQoNCiAgICAgICAgICAgIGxl YWYgdnBuLWlkIHsNCiAgICAgICAgICAgICAgICDigKYNCiAgICAgICAgICAgIH0NCiAgICAgICAg ICAgIC4uLg0KICAgICAgICAgICAgbGlzdCBleHRyYW5ldC12cG4tcG9saWN5IHsNCiAgICAgICAg ICAgICAgICBrZXkgdnBuLWlkOw0KICAgICAgICAgICAgICAgIGxlYWYgdnBuLWlkIHsNCiAgICAg ICAgICAgICAgICAgICAgdHlwZSBzdmMtaWQ7DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAg ICAgfQ0KICAgICAgICANCiAgICAgICAgICAgIGxpc3Qgc2l0ZXN7DQogICAgICAgICAgICAgIGxl YWYgc2l0ZS1pZA0KICAgICAgICAgICAgICBsZWFmIHNpdGUtcm9sZQ0KICAgICAgICAgICAgICBs ZWFmcmVmIHBhdGggIi9sM3Zwbi1zdmMvc2l0ZS10ZW1wbGF0ZXMvc2l0ZS10ZW1wbGF0ZS1pZCIg ICAgDQogICAgICAgICAgICB9DQogICAgICAgIH0NCg0KICAgICAgICBsaXN0IHNpdGUtdGVtcGxh dGVzew0KICAgICAgICAuLi4gDQogICAgICAgIH0NCiAgICAgICAgLi4uDQogICAgfQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE9nYWtpLCBLZW5pY2hpDQpTZW50OiBXZWRuZXNkYXksIEZl YnJ1YXJ5IDI0LCAyMDE2IDQ6MzQgUE0NClRvOiAnQWlqdW4gV2FuZyc7IHN0ZXBoYW5lLmxpdGtv d3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0wzc21dIElzc3Vl ICMxMCBSRTogTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGlu dGVyaW0gc2Vzc2lvbg0KDQpIaSBBaWp1biwNCg0KPldpdGhpbiB0aGUgY3VycmVudCBZYW5nIG1v ZGVsLCBpdCBpcyBub3QgbG9vc2UgY291cGxlZCBmb3IgdGhlIHZwbiBhbmQgDQo+c2l0ZXMuIEV2 ZXJ5IHNpdGUgaXMgYXNzb2NpYXRlZCB3aXRoIGF0IGxlYXN0IG9uZSB2cG4tcG9saWN5IGVudHJ5 Lg0KDQpJIHdhbnRlZCB0byBtZWFuIGJ5IGxvb3NlIGNvdXBsaW5nIHRoYXQgdnBuIGFuZCBzaXRl IHNob3VsZCBiZSBzdHJ1Y3R1cmFsbHkgYXQgdGhlIHNhbWUgbGV2ZWwuIFRoaXMgbWVhbnMgdGhh dCBhIGtpbmQgb2YgZ3JhcGggc3RydWN0dXJlIGlzIGJldHRlciB0aGFuIGEgaGllcmFyY2hpY2Fs IHN0cnVjdHVyZS4NCkluIGEgVlBOIHNlcnZpY2UsIGl04oCZcyBuYXR1cmFsIHRoYXQgYSBzaXRl IG11c3QgYmVsb25nIHRvIGF0IGxlYXN0IG9uZSB2cG4uDQoNCg0KPlRoZSByZWFzb24gdGhhdCBJ IHByZWZlciB0aGUgInZwbi0tPnNpdGUiIHN0cnVjdHVyZSB0byAic2l0ZS0tPnZwbiIgDQo+c3Ry dWN0dXJlIGlzIHRoYXQgdGhlIG1ham9yaXR5IG9mIGNvbnRhaW5lcnMgd2l0aGluIGxpc3RzICJz aXRlcyIgYXJlIA0KPnZwbi1yZWxhdGVkLCBhcyB5b3UgYWxzbyBjb25maXJtZWQgdGhpcy4NCg0K PkZyb20gdGhlIGNvbmZpZ3VyYXRpb24gdmlld3BvaW50IGluIHRoZSBjdXJyZW50IG1vZGVsLCB0 aGUgbGluayBpbmZvcm1hdGlvbiBiZXR3ZWVuIHZwbiBhbmQgc2l0ZSBjYW4gYmUgY29uZmlndXJh YmxlIG9ubHkgaW4gc2l0ZXMuIFRoYXQncyB2cG4tcG9saWN5Lg0KVGhpcyBpcyByZWFzb25hYmxl IHRvIGF2b2lkIHRoZSBpbmNvbnNpc3RlbmN5IGluIHRoZSBjYXNlIHRoYXQgYm90aCBjYW4gYmUg Y29uZmlndXJhYmxlLiANClRoaXMgaW5mb3JtYXRpb24sIHdoaWNoIHNpdGUgYmVsb25ncyB0byB3 aGljaCB2cG4sIG1heSBiZSBhYmxlIHRvIGJlIG1vdmVkIHVuZGVyIHZwbi1zdmMgYXMgYSBsaXN0 LCBidXQgSSBkb24ndCB0aGluayB0aGUgbmVjZXNzaXR5LiBJdCBtYXkgYmUgdXNlZnVsIHRvIGRl ZmluZSB0aGUgb3Atc3RhdGUgdW5kZXIgdnBuLXN2YyBhcyBkaXNjdXNzZWQgaW4gaXNzdWUjNi4N Cg0KSSBhZ3JlZWQgd2l0aCB0aGUgcHJpbmNpcGxlIHdoYXQgeW91IHdyb3RlLCBidXQgSSBkaWRu J3QgY2FyZWZ1bGx5IGRpc2N1c3MgZWFjaCBjb250YWluZXIgc2hvdWxkIGJlIHVuZGVyIHZwbi1z dmMgb3Igc2l0ZS4NCklNTywgaWYgYW55IGNvbnRhaW5lciBpcyBwbGFjZWQgaW5hcHByb3ByaWF0 ZWx5LCB3ZSBzaG91bGQganVzdCBtb3ZlIGl0IHRvIHRoZSBhcHByb3ByaWF0ZSBwbGFjZS4gSXQn cyBkaWZmZXJlbnQgcHJvYmxlbSBmcm9tIHRoZSBtb2RlbCBzdHJ1Y3R1cmUgZGlzY3Vzc2lvbi4N Cg0KDQpUaGFua3MsDQpLZW5pY2hpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWlqdW4g V2FuZw0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAyOjU3IFBNDQpUbzogJ09n YWtpLCBLZW5pY2hpJzsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbTDNzbV0gSXNzdWUgIzEwIFJFOiBMM1NNIGludGVyaW0gbWVldGlu ZyBtaW51dGVzIG9uIFRodXJzZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCkhpLCBPZ2FraToN Cg0KV2l0aGluIHRoZSBjdXJyZW50IFlhbmcgbW9kZWwsIGl0IGlzIG5vdCBsb29zZSBjb3VwbGVk IGZvciB0aGUgdnBuIGFuZCBzaXRlcy4gRXZlcnkgc2l0ZSBpcyBhc3NvY2lhdGVkIHdpdGggYXQg bGVhc3Qgb25lIHZwbi1wb2xpY3kgZW50cnkuIA0KVGhlIHJlYXNvbiB0aGF0IEkgcHJlZmVyIHRo ZSAidnBuLS0+c2l0ZSIgc3RydWN0dXJlIHRvICJzaXRlLS0+dnBuIiBzdHJ1Y3R1cmUgaXMgdGhh dCB0aGUgbWFqb3JpdHkgb2YgY29udGFpbmVycyB3aXRoaW4gbGlzdHMgInNpdGVzIiBhcmUgdnBu LXJlbGF0ZWQsIGFzIHlvdSBhbHNvIGNvbmZpcm1lZCB0aGlzLiBUaGVuIGl0IGlzIG5vdCBlbm91 Z2ggaW4gY3VycmVudCBZYW5nIG1vZGVsIHRvIGNvcnJlbGF0ZSBvbmx5IHRoZSAidnBuLXBvbGlj eSIgY29udGFpbmVyIHRvIGRpZmZlcmVudCB2cG4gaWQuDQpBbmQgb24gdGhlIG90aGVyIHdheSwg d2UgY2FuIGFsc28gdXNlIHRoZSBzaXRlLXRlbXBsYXRlIHRvIGxlc3NlbiB0aGUgYnVyZGVuIG9m IHRoZSBjdXN0b21lciBjb25maWd1cmF0aW9uLCBhcyB0aGF0IGRvbmUgaW4gY3VycmVudCBZYW5n IG1vZGVsLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT2dha2ksIEtlbmlj aGkgW21haWx0bzprZS1vb2dha2lAa2RkaS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDI0LCAyMDE2IDEyOjU5IFBNDQpUbzogJ0FpanVuIFdhbmcnOyBzdGVwaGFuZS5saXRrb3dza2lA b3JhbmdlLmNvbTsgbDNzbUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtMM3NtXSBJc3N1ZSAjMTAg UkU6IEwzU00gaW50ZXJpbSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmlt IHNlc3Npb24NCg0KSGkgQWlqdW4sDQoNCj4xLiB0aGUgc2VydmljZSBtb2RlbCBtdXN0IGJlIHNl cnZpY2Ugb3JpZW50ZWQuIElmIG9uZSBzaXRlIGJlbG9uZ3MgdG8gc2V2ZXJhbCB2cG5zLCB3ZSBz aG91bGQgYWNoaWV2ZSB0aGUgZ29hbCBieSBkZWZpbmluZyBzZXZlcmFsIHNlcnZpY2UgaW5zdGFu Y2VzLg0KPg0KPltLT10gSSBjYW4ndCBhZ3JlZSB0aGlzLiBUaGUgY2FzZSB0aGF0IGEgc2l0ZSBi ZWxvbmdzIHRvIG11bHRpcGxlIHZwbnMgaXMgYWxzbyBhIHZlcnkgY29tbW9uIHNlcnZpY2UgdXNl IGNhc2UsIHRoZW4gdGhlIHNlcnZpY2UgbW9kZWwgbXVzdCBkZXNpZ24gdGhpcyBhcHByb3ByaWF0 ZWx5Lg0KPkZvciBlYXN5IHVzZSBvZiBhIHNlcnZpY2UgbW9kZWwgYW5kIHRvIGF2b2lkIHRoZSBt aXNjb25maWd1cmF0aW9uIGFuZCBpbmNvbnNpc3RlbmN5LCB3ZSBoYXZlIHRvIGV4Y2x1ZGUgZHVw bGljYXRlIGNvbmZpZ3VyYXRpb24gZm9yIHRoZSBzYW1lIGluZm9ybWF0aW9uLCBkYXRhIG5vZGUg aW5zdGFuY2UsIGFzIG11Y2ggYXMgcG9zc2libGUuID5UaGVuLCBJIHByb3Bvc2VkIHRvIHJlbW92 ZSByZXBldGl0aXZlIGRlZmluaXRpb25zIG9mIGEgdnBuIHdoaWNoIGNhbiBiZSBpbXBsaWNpdGx5 IHVuaXF1ZWx5IGlkZW50aWZpZWQgaW4gYSBzYW1lIHRyYW5zYWN0aW9uLiBCdXQsIHRoYXQgZXZl bnR1YWxseSBjYW1lIG5vdCB0byBtYWtlIHNlbnNlIGZvciByZXN0Y29uZi4NCj5JbiB0aGF0IHNl bnNlLCBJIGJhc2ljYWxseSBwcmVmZXIgdGhlIGN1cnJlbnQgbW9kZWwuDQo+W0FpanVuIFdhbmdd OiBmb3Igc2l0ZXMgdGhhdCBiZWxvbmcgdG8gc2V2ZXJhbCB2cG5zLCBiZWNhdXNlIHdlIGRlZmlu ZSAidnBuLXN2YyIgYXMgbGlzdCwgdGhlbiBpdCBjYW4gaW5jbHVkZSBkaWZmZXJlbnQgaXRlbXMs IGVhY2ggdnBuLXN2YyBpdGVtIGNhbiBkZWZpbmUgaXRzIG93biBzaXRlcyBjb3ZlcmFnZSBpbmZv cm1hdGlvbi4gPlRoZXJlIGlzIGFsc28gbm8gZHVwbGljYXRlIGNvbmZpZ3VyYXRpb24gZm9yIHRo aXMgc29sdXRpb24uIFdoYXQncyB0aGUgcHJvYmxlbSB0aGVuIGZvciB0aGlzIGFycmFuZ2VtZW50 Pw0KDQpJZiBhIHBoeXNpY2FsIGN1c3RvbWVyIHNpdGUgY29ubmVjdHMgdG8gdHdvIGRpZmZlcmVu dCB2cG5zIGluIHRoaXMgY2FzZSwgdGhlIGN1c3RvbWVyIG11c3QgaW5wdXQgb3IgdXBkYXRlIHRo ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgKHBoeXNpY2FsKSBzaXRlIGR1cGxpY2F0ZWx5IHBlciB2 cG4tc3ZjLiBUaGlzIG1heSBjYXVzZSBtaXNjb25maWd1cmF0aW9uIGFuZCBib3RoZXIgb3VyIGN1 c3RvbWVycy4NCkFub3RoZXIgY29uY2VybiBpcyB0aGUgaW5jb25zaXN0ZW5jeSB3aXRoIGFjY291 bnRpbmcvY2hhcmdpbmcgbW9kZWwsIHdoZW4gYW4gb3BlcmF0b3IgY2hhcmdlcyB0aGUgZmVlIGZv ciBwaHlzaWNhbCBhY2Nlc3MsIGl0IGJlY29tZXMgaW5jb25zaXN0ZW50IHdpdGggdGhlIGNoYXJn aW5nIG1vZGVsLiBXaGVuIHdlIGRvZXMgYSB0cmFmZmljIGFjY291bnRpbmcgbm90IG9ubHkgZm9y IGxvZ2ljYWwgYWNjZXNzIHBlciB2cG4sIGJ1dCBhbHNvIGZvciBwaHlzaWNhbCBhY2Nlc3MsIHdl IG11c3QgYWx3YXlzIHRha2UgY2FyZSBvZiB0aGUgZXhpc3RlbmNlIG9mIGRpZmZlcmVudCB2cG4t c3ZjIHdpdGggdGhlIHNhbWUgcGh5c2ljYWwgYWNjZXNzIGluIG9yZGVyIHRvIHRyaWdnZXIgYSBw b2xsaW5nIHRyYWZmaWMgY291bnRlciBvZiB0aGUgaW50ZXJmYWNlIG9uIFBFLg0KDQpJIHVuZGVy c3RhbmQgaXQgZGVwZW5kcyBvbiBlYWNoIG9wZXJhdG9yJ3Mgc2VydmljZSBkZWZpbml0aW9uLCB2 cG4gc3BlY2lmaWMgb3Igc2l0ZSBzcGVjaWZpYywgYXMgU3RlcGhhbmUgd3JvdGUuDQoNClRvIGFj Y29tbW9kYXRlIHRoZXNlIGRpZmZlcmVudCByZXF1aXJlbWVudHMsIEkgdGhpbmsgdGhlIGxvb3Nl IGNvdXBsZWQgbW9kZWwgYmV0d2VlbiB0aGUgY29tcG9uZW50cywgdnBuIGFuZCBzaXRlLCBzZWVt cyBiZXR0ZXIuDQoNClRoYW5rcywNCktlbmljaGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBBaWp1biBXYW5nDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjA2IEFN DQpUbzogJ09nYWtpLCBLZW5pY2hpJzsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IGwz c21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTDNzbV0gSXNzdWUgIzEwIFJFOiBMM1NNIGludGVy aW0gbWVldGluZyBtaW51dGVzIG9uIFRodXJzZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCkhp LCBPZ2FraToNCg0KUGxlYXNlIHNlZSB0aGUgcmVwbHkgaW5saW5lLg0KDQoNCkJlc3QgUmVnYXJk cy4NCg0KQWlqdW4gV2FuZw0KDQpDaGluYSBUZWxlY29tIENvcnBvcmF0aW9uIExpbWl0ZWQgQmVp amluZyBSZXNlYXJjaCBJbnN0aXR1dGUgTmV0d29yayBSZXNlYXJjaCBhbmQgT3BlcmF0aW9uIFN1 cHBvcnQgRGVwYXJ0bWVudA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT2dh a2ksIEtlbmljaGkgW21haWx0bzprZS1vb2dha2lAa2RkaS5jb21dDQpTZW50OiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDI0LCAyMDE2IDg6MTEgQU0NClRvOiAnQWlqdW4gV2FuZyc7IHN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0wzc21dIElz c3VlICMxMCBSRTogTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NN IGludGVyaW0gc2Vzc2lvbg0KDQpIaSBBaWp1biwNCg0KU2VlIGNvbW1lbnRzIGlubGluZSwgcGxl YXNlLg0KDQpUaGFua3MsDQpLZW5pY2hpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWlq dW4gV2FuZw0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDE4LCAyMDE2IDE6MTIgUE0NClRvOiAn T2dha2ksIEtlbmljaGknOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtMM3NtXSBJc3N1ZSAjMTAgUkU6IEwzU00gaW50ZXJpbSBtZWV0 aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KSGksIFN0ZXBo YW5lIGFuZCBPZ2FraToNCg0KIA0KDQpJIHN1Z2dlc3RlZCB3ZSBwdXQgdGhlICJleHRyYW5ldC12 cG4tcG9saWN5IiB1bmRlciB0aGUgbGlzdCAidnBuLXN2YyIgZGlyZWN0bHksIG5vdCBpbiB0aGUg Y29udGFpbmVyICJ2cG4tcG9saWN5IiB0aGF0IGlzIG5vdyB1bmRlciB0aGUgbGlzdCAic2l0ZXMi IGluIGN1cnJlbnQgbW9kZWwuIA0KDQpbS09dTGlrZSB0aGlzPw0KDQogICAgY29udGFpbmVyIGwz dnBuLXN2YyB7DQogICAgICAgIGxpc3QgdnBuLXN2YyB7DQogICAgICAgICAgICBrZXkgdnBuLWlk Ow0KDQogICAgICAgICAgICBsZWFmIHZwbi1pZCB7DQogICAgICAgICAgICAgICAg4oCmDQogICAg ICAgICAgICB9DQogICAgICAgICAgICAuLi4NCiAgICAgICAgICAgIGxpc3QgZXh0cmFuZXQtdnBu LXBvbGljeSB7DQogICAgICAgICAgICAgICAga2V5IHZwbi1pZDsNCiAgICAgICAgICAgICAgICBs ZWFmIHZwbi1pZCB7DQogICAgICAgICAgICAgICAgICAgIHR5cGUgc3ZjLWlkOw0KICAgICAgICAg ICAgICAgIH0NCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIC4uLg0KICAgICAgICB9DQogICAg ICAgIC4uLg0KICAgIH0NCltBaWp1biBXYW5nXTogWWVzLg0KDQpUaGlzIGNhbiBzb2x2ZSB0aGUg aW5pdGlhbCBzY2VuYXJpbyB0aGF0IHByb3Bvc2VkIGJ5IEtlbmljaGkgYXQgdGhlIGJlZ2lubmlu ZyBvZiBvdXIgZGlzY3Vzc2lvbi4gV2hlbiB0aGUgb3JjaGVzdHJhdG9yIHJlY2VpdmVzIHRoZSBp bmZvcm1hdGlvbiBkZWZpbmVkIGluICJleHRyYW5ldC12cG4tcG9saWN5IiwgaXQgY2FuIGFsbG9j YXRlIG5ldyByb3V0ZS10YXJnZXQgZm9yIHRoZSBpbnZvbHZlZCBWUE5zIGFuZCBzZXQgdGhlbSBp biB0aGUgY29uZmlndXJhdGlvbiBzdGFuemEgb2YgZWFjaCByb3V0ZXIuDQoNCiANCg0KRm9yIHRo ZSByZWxhdGlvbnNoaXAgb2YgbGlzdCAidnBuLXN2YyIgYW5kIGxpc3QgInNpdGVzIiwgSSBzdGls bCBzdWdnZXN0IHdlIHB1dCB0aGUgbGlzdCAic2l0ZSIgdW5kZXIgdGhlICJ2cG4tc3ZjIiwgdGhl IHJlYXNvbiBmb3IgZG9pbmcgdGhpcyBpcyBhcyBiZWxvdzoNCg0KMS4gdGhlIHNlcnZpY2UgbW9k ZWwgbXVzdCBiZSBzZXJ2aWNlIG9yaWVudGVkLiBJZiBvbmUgc2l0ZSBiZWxvbmdzIHRvIHNldmVy YWwgdnBucywgd2Ugc2hvdWxkIGFjaGlldmUgdGhlIGdvYWwgYnkgZGVmaW5pbmcgc2V2ZXJhbCBz ZXJ2aWNlIGluc3RhbmNlcy4NCg0KW0tPXSBJIGNhbid0IGFncmVlIHRoaXMuIFRoZSBjYXNlIHRo YXQgYSBzaXRlIGJlbG9uZ3MgdG8gbXVsdGlwbGUgdnBucyBpcyBhbHNvIGEgdmVyeSBjb21tb24g c2VydmljZSB1c2UgY2FzZSwgdGhlbiB0aGUgc2VydmljZSBtb2RlbCBtdXN0IGRlc2lnbiB0aGlz IGFwcHJvcHJpYXRlbHkuDQpGb3IgZWFzeSB1c2Ugb2YgYSBzZXJ2aWNlIG1vZGVsIGFuZCB0byBh dm9pZCB0aGUgbWlzY29uZmlndXJhdGlvbiBhbmQgaW5jb25zaXN0ZW5jeSwgd2UgaGF2ZSB0byBl eGNsdWRlIGR1cGxpY2F0ZSBjb25maWd1cmF0aW9uIGZvciB0aGUgc2FtZSBpbmZvcm1hdGlvbiwg ZGF0YSBub2RlIGluc3RhbmNlLCBhcyBtdWNoIGFzIHBvc3NpYmxlLiBUaGVuLCBJIHByb3Bvc2Vk IHRvIHJlbW92ZSByZXBldGl0aXZlIGRlZmluaXRpb25zIG9mIGEgdnBuIHdoaWNoIGNhbiBiZSBp bXBsaWNpdGx5IHVuaXF1ZWx5IGlkZW50aWZpZWQgaW4gYSBzYW1lIHRyYW5zYWN0aW9uLiBCdXQs IHRoYXQgZXZlbnR1YWxseSBjYW1lIG5vdCB0byBtYWtlIHNlbnNlIGZvciByZXN0Y29uZi4NCklu IHRoYXQgc2Vuc2UsIEkgYmFzaWNhbGx5IHByZWZlciB0aGUgY3VycmVudCBtb2RlbC4NCltBaWp1 biBXYW5nXTogZm9yIHNpdGVzIHRoYXQgYmVsb25nIHRvIHNldmVyYWwgdnBucywgYmVjYXVzZSB3 ZSBkZWZpbmUgInZwbi1zdmMiIGFzIGxpc3QsIHRoZW4gaXQgY2FuIGluY2x1ZGUgZGlmZmVyZW50 IGl0ZW1zLCBlYWNoIHZwbi1zdmMgaXRlbSBjYW4gZGVmaW5lIGl0cyBvd24gc2l0ZXMgY292ZXJh Z2UgaW5mb3JtYXRpb24uIFRoZXJlIGlzIGFsc28gbm8gZHVwbGljYXRlIGNvbmZpZ3VyYXRpb24g Zm9yIHRoaXMgc29sdXRpb24uIFdoYXQncyB0aGUgcHJvYmxlbSB0aGVuIGZvciB0aGlzIGFycmFu Z2VtZW50PyANCg0KDQoyLiBUaGUgYXR0cmlidXRlcyBvZiAic2l0ZXMiLCBzdWNoIGFzICJtYXhp bXVtLXJvdXRlcyIsICJzZWN1cml0eSIsICJzZXJ2aWNlIiwgInJvdXRpbmctcHJvdG9jb2xzIiwi c2l0ZS1uZXR3b2stYWNjZXNzZXMiIGV0Yy4gYXJlIGFsbCBzZXJ2aWNlL3NpdGUgcm9sZSByZWxh dGVkLCB0aGF0IGlzIHRvIHNheSwgaWYgdGhlIHNpdGUgcm9sZSBjaGFuZ2VkLCBhbGwgb2YgdGhl c2UgYXR0cmlidXRlZCBtYXkgYmUgY2hhbmdlZCBhY2NvcmRpbmdseS4NCg0KDQpbS09dIEkgYmFz aWNhbGx5IGFncmVlLiBUaGUgYXR0cmlidXRlcyB0aWVkIHRvIGEgd2hvbGUgdnBuIGFuZCBnbG9i YWxseSBhcHBsaWVkIHRvIGFsbCB0aGUgc2l0ZXMgdW5kZXIgdGhlIHZwbiBzaG91bGQgYmUgZGVm aW5lZCB3aXRoIHRoZSB2cG4gZGVmaW5pdGlvbi4NCg0KDQozLkZvciBjb250YWluZXIgInZwbiBw b2xpY3kiIHRoYXQgdW5kZXIgbGlzdCAic2l0ZXMiIGluIGN1cnJlbnQgbW9kZWwsIHRoZXJlIGFy ZSB0d28gaW5mb3JtYXRpb24gZGVmaW5lZCwgb25lIGlzICJmaWx0ZXIiIGZvciBwcmVmaXggZmls dGVyaW5nLCBhbm90aGVyIGlzICJzaXRlLXJvbGUiLiBJIHN1Z2dlc3Qgd2Ugc3BsaXQgaXQsIHB1 dCB0aGUgbGVhZiAic2l0ZS1yb2xlIiB1bmRlciBsZWFmICJzaXRlLWlkIiBkaXJlY3RseSwgYW5k IGNoYW5nZSB0aGUgbmFtZSBvZiAidnBuLXBvbGljeSIgdG8gInNpdGUtcHJlZml4LXBvbGljeSIu IA0KDQogDQoNClRoZSBmaW5hbCBzdWdnZXN0IHN0cnVjdHVyZSBvZiB0aGUgTDNWUE4geWFuZyBt b2RlbCB3aWxsIGJlIGxvb2sgbGlrZSB0aGUgYmVsbG93LCBJIHVuZGVybGluZSB0aGUgY2hhbmdl ZCBwb3NpdGlvbnMgZnJvbSB0aGUgY3VycmVudCBsM3ZwbiBZYW5nIE1vZGVsDQoNCiANCg0KQ29u dGFpbmVyIEwzdnBuLXN2Yw0KDQogICBMaXN0IHZwbi1zdmMNCg0KICAgTGVhZiB2cG4taWQNCg0K ICAgTGVhZiBjdXN0b21lci1uYW1lDQoNCiAgIExlYWYgdG9wb2xvZ3kNCg0KICAgTGlzdCBleHRy YW5ldC12cG4tcG9saWN5DQoNCiAgIENvbnRhaW5lciBjbG91ZC1hY2Nlc3MNCg0KICAgTGlzdCBt dWx0aWNhc3QNCg0KICAgTGVhZiBtcGxzDQoNCiAgIExpc3QgdHJhbnNwb3J0LWNvbnRyYWludHMN Cg0KICAgDQoNCiAgIExpc3Qgc2l0ZXMNCg0KICAgICBMZWFmIHNpdGUtaWQNCg0KICAgICBMZWFm IHNpdGUtcm9sZQ0KDQogICAgIGxlYWYgYXBwbHktdGVtcGxhdGUNCg0KICAgICAuLi4gLi4uDQoN CiAgICAgLi4uIC4uLg0KDQogICAgIENvbnRhaW5lciBtYW5hZ2VudA0KDQogICAgIENvbnRhaW5l ciBzaXRlLXByZWZpeC1wb2xpY3kNCg0KICAgICBDb250YWluZXIgbWF4aW11bS1yb3V0ZXMNCg0K ICAgICBDb250YWluZXIgc2VjdXJpdHkNCg0KICAgICAuLi4gLi4uDQoNCiAgICAgLi4uIC4uLg0K DQogICAgIFNpdGUtbmV0d29yay1hY2Nlc3MgDQoNCiANCg0KIA0KDQpXaGV0aGVyIGlzIGl0IG1v cmUgcmVhc29uYWJsZT8gDQoNCiANCg0KIA0KDQpCZXN0IFJlZ2FyZHMuDQoNCiANCg0KQWlqdW4g V2FuZw0KDQogDQoNCkNoaW5hIFRlbGVjb20gQ29ycG9yYXRpb24gTGltaXRlZCBCZWlqaW5nIFJl c2VhcmNoIEluc3RpdHV0ZSANCg0KTmV0d29yayBSZXNlYXJjaCBhbmQgT3BlcmF0aW9uIFN1cHBv cnQgRGVwYXJ0bWVudA0KDQogDQoNCiANCg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE9nYWtpLCBLZW5pY2hpDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTgsIDIwMTYgOTowOCBB TQ0KVG86IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFtMM3NtXSBJc3N1ZSAjMTAgUkU6IEwzU00g aW50ZXJpbSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24N Cg0KIA0KDQpIaSBTdGVwaGFuZSBhbmQgQWxsLA0KDQogDQoNCkFzIGZvciBpc3N1ZSAjMTAgaXRz ZWxmLCB0aGUgZm9sbG93aW5nIHNvbHV0aW9uIGNhbiBiZSBhY2NlcHRhYmxlIGZvciB1cy4NCg0K IA0KDQo+T25lIHByb3Bvc2FsIGNvdWxkIGJlIHRvIG5vdCBjYWxsIHRoaXMgVlBOIHBvbGljeSwg YnV0IGNyZWF0aW5nIGENCg0KPmNvbnRhaW5lciAiZXh0cmFuZXQtdnBuLXBvbGljeSIgYXQgdnBu IGxldmVsIHdoaWNoIHdpbGwgbWFuZGF0ZSBhbiBleHRyYW5ldCBWUE4gYXJjaGl0ZWN0dXJlIGZy b20gYSBjb25maWd1cmF0aW9uIHBvaW50IG9mIHZpZXcsIGRlZHVjaW5nIGF1dG9tYXRpY2FsbHkg dGhlIGFwcHJvcHJpYXRlIFJUIHJ1bGVzIHRvIGFkZCAobGlrZSBjcmVhdGluZyBhIG5ldyBwYWly IG9mIFJUcykuDQoNCiANCg0KV2hhdCBtb2RlbCBpcyBpbiB5b3VyIG1pbmQ/IEkgY2FuJ3Qgc2Vl IHdoYXQgIiJleHRyYW5ldC12cG4tcG9saWN5IiBhdCB2cG4iIG1lYW5zLg0KDQpMaWtlIHRoaXM/ DQoNCiANCg0KPHZwbi1zdmM+DQoNCiAgIC4uLg0KDQogICA8dnBuLXBvbGljeT4NCg0KICAgICAg IDxlbnRyaWVzPg0KDQogICAgICAgICAgIDxpZD4xPC9pZD4NCg0KICAgICAgICAgICA8dnBuPg0K DQogICAgICAgICAgICAgICA8dnBuLWlkPlZQTjE8L3Zwbi1pZD4NCg0KICAgICAgICAgICA8L3Zw bj4NCg0KICAgICAgICAgICA8ZXh0cmFuZXQtdnBuLXBvbGljeT4NCg0KICAgICAgICAgICAgICAg PGV4dHJhbmV0LXZwbj4NCg0KICAgICAgICAgICAgICAgICAgIDx2cG4taWQ+VlBOMjwvdnBuLWlk Pg0KDQogICAgICAgICAgICAgICA8L2V4dHJhbmV0LXZwbj4NCg0KICAgICAgICAgICA8L2V4dHJh bmV0LXZwbi1wb2xpY3k+DQoNCiAgICAgICA8L2VudHJpZXM+DQoNCiAgIDwvdnBuLXBvbGljeT4N Cg0KICAgLi4uDQoNCjwvdnBuLXN2Yz4NCg0KIA0KDQpUaGFua3MsDQoNCktlbmljaGkNCg0KIA0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1i b3VuY2VzQGlldGYub3JnIDxtYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnPiBdIE9uIEJlaGFs ZiBPZiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSA8bWFpbHRvOnN0ZXBoYW5lLmxpdGtv d3NraUBvcmFuZ2UuY29tPiANCg0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAwNywgMjAxNSAxMTo0 NSBQTQ0KDQpUbzogT2dha2ksIEtlbmljaGk7ICdBaWp1biBXYW5nJzsgJ1FpbiBXdSc7IGwzc21A aWV0Zi5vcmcgPG1haWx0bzpsM3NtQGlldGYub3JnPiANCg0KQ2M6IGFkcmlhbkBvbGRkb2cuY28u dWsgPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPiANCg0KU3ViamVjdDogUmU6IFtMM3NtXSBM M1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9uIFRodXJzZGF5IEwzU00gaW50ZXJpbSBzZXNz aW9uDQoNCiANCg0KSGkgS2VuaWNoaSwNCg0KIA0KDQpSZWdhcmRpbmcgeW91ciBwcm9wb3NhbCBv ZiBoYXZpbmcgYSBzaW1wbGUgVlBOIHBvbGljeSBpbiB0aGUgdnBuLXN2YyBjb250YWluZXIsIEkg ZG8gc2VlIGFuIGlzc3VlLiBPbmUgb2YgdGhlIGtleSBwb2ludCBvZiB0aGUgVlBOIHBvbGljeSBp cyB0byBleHByZXNzIHRoZSByb2xlIG9mIHRoZSBzaXRlIGluIHRoZSB0YXJnZXQgVlBOIHRvcG9s b2d5Lg0KDQpJZiB3ZSBkbyBhIHZwbiBwb2xpY3kgYXQgVlBOIGxldmVsLCB3ZSBjYW5ub3QgYW55 bW9yZSBkZXNjcmliZSBzaXRlIHJvbGVzIGluIHRoZSB0YXJnZXQgVlBOIHdoaWNoIGNhdXNlcyBh biBpc3N1ZS4NCg0KSW4gYW4gaWRlYWwgd29ybGQgd2hlcmUgYWxsIFZQTnMgYXJlIGFueSB0byBh bnksIHRoZSBzaXRlIHJvbGUgaXMgYWx3YXlzIHRoZSBzYW1lIGFuZCB0aGVyZSBpcyBubyBpc3N1 ZSwgYnV0IGxldCdzIHRoaW5rIGFib3V0IHNvbWVvbmUgdHJ5aW5nIHRvIHVzZSB0aGUgdnBuLXBv bGljeSAoYXQgdnBuIGxldmVsKSB0byBjb25uZWN0IHRvIGEgSHViICYgU3Bva2UgVlBOLCBob3cg ZG8geW91IGRlZHVjZSB0aGUgcm9sZXMgb2YgdGhlIHNpdGVzID8NCg0KIA0KDQpPbmUgcHJvcG9z YWwgY291bGQgYmUgdG8gbm90IGNhbGwgdGhpcyBWUE4gcG9saWN5LCBidXQgY3JlYXRpbmcgYSBj b250YWluZXIgImV4dHJhbmV0LXZwbi1wb2xpY3kiIGF0IHZwbiBsZXZlbCB3aGljaCB3aWxsIG1h bmRhdGUgYW4gZXh0cmFuZXQgVlBOIGFyY2hpdGVjdHVyZSBmcm9tIGEgY29uZmlndXJhdGlvbiBw b2ludCBvZiB2aWV3LCBkZWR1Y2luZyBhdXRvbWF0aWNhbGx5IHRoZSBhcHByb3ByaWF0ZSBSVCBy dWxlcyB0byBhZGQgKGxpa2UgY3JlYXRpbmcgYSBuZXcgcGFpciBvZiBSVHMpLiBUaGlzIG1lYW5z IHRoYXQgdGhlIHVzYWdlIGlzIHJlYWxseSBsaW1pdGVkIHRvICJzaW1wbGUiIGV4dHJhbmV0LXZw bnMgYW5kIGl0IGRvZXMgbm90IHJlcGxhY2Ugbm9yIGNvbXBldGUgd2l0aCB0aGUgVlBOIHBvbGlj eSBhdCBzaXRlIGxldmVsLg0KDQogDQoNCkNvdWxkIGl0IGJlIGEgZ29vZCBjb21wcm9taXNlID8N Cg0KIA0KDQpTdGVwaGFuZQ0KDQogDQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cg0KRnJvbTogT2dha2ksIEtlbmljaGkgW21haWx0bzprZS1vb2dha2lAa2RkaS5jb20gPG1haWx0 bzprZS1vb2dha2lAa2RkaS5jb20+IF0NCg0KU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDA1LCAy MDE1IDA2OjIzDQoNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL09JTklTOyAnQWlqdW4gV2Fu Zyc7ICdRaW4gV3UnOyBsM3NtQGlldGYub3JnIDxtYWlsdG86bDNzbUBpZXRmLm9yZz4gDQoNCkNj OiBhZHJpYW5Ab2xkZG9nLmNvLnVrIDxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4gDQoNClN1 YmplY3Q6IFJFOiBbTDNzbV0gTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2Rh eSBMM1NNIGludGVyaW0gc2Vzc2lvbg0KDQogDQoNCkRlYXIgU3RlcGhhbmUgYW5kIEFsbCwNCg0K IA0KDQpJIGRvbid0IHNheSB0aGF0IHNpdGVzICptdXN0KiBtb3ZlIHVuZGVyIHZwbi1zdmMgYmVj YXVzZSBJIHVuZGVyc3RhbmQgc3RlcGhhbmUncyB1c2UgY2FzZS4NCg0KQnV0IHdlIGFscmVhZHkg aGF2ZSB2cG4tc3ZjIGFuZCBzb21lIHBhcmFtZXRlcnMgdW5kZXIgdGhpcyBhcmUgZ2xvYmFsbHkg YXBwbGllZCB0byBhbGwgdGhlIHNpdGVzIGV2ZW4gaW4gdGhlIGN1cnJlbnQgbW9kZWwuDQoNCiAN Cg0KSXQgZGVwZW5kcyBvbiBvcGVyYXRvcidzIHVzZSBjYXNlIHdoaWNoIGlzIHNpdGUtb3JpZW50 ZWQgb3IgdnBuLW9yaWVudGVkIHNlcnZpY2UuDQoNCk91ciBzZXJ2aWNlIGlzIHZwbi1vcmllbnRl ZCwgc2l0ZSBoYXMgdGhlIG5hdGl2ZSBWUE4uIFRoZW4sIEkgd291bGQganVzdCBsaWtlIHlvdSB0 byBhbGxvdyBvdGhlciBnbG9iYWwgb3B0aW9ucyB0byB2cG4tc3ZjLg0KDQogDQoNClRoYW5rcywN Cg0KS2VuaWNoaQ0KDQogDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IHN0 ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIDxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb20+ICBbbWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIDxtYWlsdG86 c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+IF0NCg0KU2VudDogRnJpZGF5LCBEZWNlbWJl ciAwNCwgMjAxNSA4OjE3IFBNDQoNClRvOiBBaWp1biBXYW5nOyAnT2dha2ksIEtlbmljaGknOyAn UWluIFd1JzsgbDNzbUBpZXRmLm9yZyA8bWFpbHRvOmwzc21AaWV0Zi5vcmc+IA0KDQpDYzogYWRy aWFuQG9sZGRvZy5jby51ayA8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+IA0KDQpTdWJqZWN0 OiBSRTogW0wzc21dIEwzU00gaW50ZXJpbSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNT TSBpbnRlcmltIHNlc3Npb24NCg0KIA0KDQpIaSwNCg0KIA0KDQpJJ20gYWdhaW5zdCB0aGlzIHBy b3Bvc2FsLCBhcyBJIGRvIG5vdCB3YW50IHRvIGNyZWF0ZSBhbnkgZGVwZW5kZW5jeSBiZXR3ZWVu IGEgcGFydGljdWxhciBWUE4gYW5kIGEgbGlzdCBvZiBzaXRlcy4NCg0KQSBzaXRlIGNhbiBiZWxv bmcgdG8gbXVsdGlwbGUgVlBOcyB3aXRoIGFueSBraW5kIG9mIHRvcG9sb2d5LCBpZiB3ZSBhdHRh Y2ggdGhlIHNpdGUgdG8gYSBzaW5nbGUgVlBOLCB3ZSBjb21lIGJhY2sgdG8gdGhlIG5vdGlvbiBv ZiAibmF0aXZlIFZQTiIgd2UgaGFkIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIG1vZGVsIHdoaWNo IHdhcyBoYXJkIHRvIHVuZGVyc3RhbmQgYW5kIHNvIHdhcyByZW1vdmVkLg0KDQogDQoNCiANCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91 bmNlc0BpZXRmLm9yZyA8bWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZz4gXSBPbiBCZWhhbGYg T2YgQWlqdW4gV2FuZw0KDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDA0LCAyMDE1IDAyOjQ0DQoN ClRvOiAnT2dha2ksIEtlbmljaGknOyAnUWluIFd1JzsgbDNzbUBpZXRmLm9yZyA8bWFpbHRvOmwz c21AaWV0Zi5vcmc+IA0KDQpDYzogYWRyaWFuQG9sZGRvZy5jby51ayA8bWFpbHRvOmFkcmlhbkBv bGRkb2cuY28udWs+IA0KDQpTdWJqZWN0OiBSZTogW0wzc21dIEwzU00gaW50ZXJpbSBtZWV0aW5n IG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KIA0KDQpEZWFyIGFs bDoNCg0KIA0KDQpDYW4gd2UgcHV0IHRoZSBsaXN0ICJzaXRlcyIgd2l0aGluIHRoZSBsaXN0ICJ2 cG4tc3ZjIiwgYW5kIGRlZmluZSB0aGUgZ2VuZXJhbCB2cG4gcG9saWN5IGZvciBhbGwgc2l0ZXMg dGhhdCB3aXRoaW4gdGhlIGNvcnJlc3BvbmRpbmcgdnBuIHNlcnZpY2UgaW5zdGFuY2U/DQoNCklm IGRvaW5nIHNvLCBzb21lIGVudHJpZXMgd2l0aGluIHRoZSBjdXJyZW50IGxpc3QgInNpdGVzIiBj YW4gYWxzbyBiZSBkcmFnZ2VkIG91dCBmb3IgZ2VuZXJhbCB1c3VhbCBwdXJwb3NlcywgZm9yIGV4 YW1wbGUsICJtYXhpbXVtLXJvdXRlcyIsICJzZWN1cml0eSIgZXRjLiBUaGVzZSBwYXJhbWV0ZXJz IGFyZSBvZnRlbiBhbGwgc2FtZSBmb3IgZXZlcnkgc2l0ZSB3aXRoaW4gb25lIFZQTiBzZXJ2aWNl IGluc3RhbmNlLiANCg0KIA0KDQpJZiBzb21lIHNpdGVzIGhhdmUgc3BlY2lhbCByZXF1aXJlbWVu dHMsIHdlIGNhbiBhY2hpZXZlIHRoaXMgYnkgdXNpbmcgc29tZSBzcGVjaWFsICJzaXRlLXZwbi1w b2xpY3kiIHdpdGhpbiB0aGUgY29ycmVzcG9uZGluZyBzaXRlIGRlZmluaXRpb24uDQoNCklzIHRo aXMgbW9yZSBhY2NlcHRhYmxlIGZvciBjdXN0b21lcnM/DQoNCiANCg0KIA0KDQpCZXN0IFJlZ2Fy ZHMuDQoNCiANCg0KQWlqdW4gV2FuZw0KDQogDQoNCkNoaW5hIFRlbGVjb20gQ29ycG9yYXRpb24g TGltaXRlZCBCZWlqaW5nIFJlc2VhcmNoIEluc3RpdHV0ZSBJbnRlbGxpZ2VudCBOZXR3b3JrIFBy b2R1Y3QgTGluZQ0KDQogDQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJv bTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOmwzc20tYm91bmNl c0BpZXRmLm9yZz4gXSBPbiBCZWhhbGYgT2YgT2dha2ksIEtlbmljaGkNCg0KU2VudDogRnJpZGF5 LCBEZWNlbWJlciAwNCwgMjAxNSA5OjAyIEFNDQoNClRvOiAnUWluIFd1JzsgbDNzbUBpZXRmLm9y ZyA8bWFpbHRvOmwzc21AaWV0Zi5vcmc+IA0KDQpDYzogYWRyaWFuQG9sZGRvZy5jby51ayA8bWFp bHRvOmFkcmlhbkBvbGRkb2cuY28udWs+IA0KDQpTdWJqZWN0OiBSZTogW0wzc21dIEwzU00gaW50 ZXJpbSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0K IA0KDQpEZWFyIEFsbCwNCg0KIA0KDQpJdCB3YXMgZ29vZCBoYXZpbmcgZGlzY3Vzc2lvbi4NCg0K IA0KDQpBcyBmb3IgaXNzdWUjMTAsIHRoZSBvYmplY3RpdmUgYW5kIHByb2JsZW0gd2UgZGlzY3Vz c2VkIGluIHRoZSBtZWV0aW5nIGFzIGZvbGxvd3MuDQoNCiANCg0KVGhlIG9iamVjdGl2ZSBpcyB0 byBwcm92aWRlIHBlci1WUE4gZXh0cmFuZXQgc2VydmljZSB3aGljaCBjb25uZWN0cyB0d28gZGlm ZmVyZW50IFZQTnMgKGUuZy4gVlBOMSBhbmQgVlBOMikuIEl0IG1lYW5zIHRoYXQgYW55IHNpdGVz IGluIFZQTjEgY2FuIGFjY2VzcyB0byBhbnkgc2l0ZXMgaW4gVlBOMi4NCg0KVGhlIHByb2JsZW0g aXMgdGhhdCB0aGUgY3VycmVudCBtb2RlbCBtdXN0IHVwZGF0ZSB2cG4tcG9saWN5IHVuZGVyIGFs bCB0aGUgc2l0ZXMgYmVsb25nIHRvIHRoZXNlIHR3byBWUE5zIGluIG9yZGVyIHRvIG9mZmVyIHRo aXMgc2VydmljZS4gRXNwZWNpYWxseSB3aGVuIHRoaXMgbW9kZWwgaXMgdXNlZCBhcyBhIGN1c3Rv bWVyIHNlbGYtY29udHJvbCBBUEksIGl0J3Mgbm90IGdvb2QgaWRlYSB0byByZXF1aXJlIGN1c3Rv bWVycyB0byB1cGRhdGUgdGhlIGluZm9ybWF0aW9uIG9mIGFsbCB0aGUgc2l0ZXMuIChJdCdzIG5v dCBhYnN0cmFjdGVkIHdheSwgYSBzZXJ2aWNlIG1vZGVsIHNob3VsZCBwcm92aWRlIHdoYXQgdGhl IGNvbnN1bWVyIHdhbnRzLCBub3QgaG93LikgSWYgYSBzZXJ2aWNlIG9yIGN1c3RvbWVyIHJlcXVp cmVzIHRvIGNvbnRyb2wgcGVyLXNpdGUgdnBuLXBvbGljeSwgdGhhdCBvZiBjdXJyZW50IG1vZGVs IHNob3VsZCBiZSB1c2VkIHdpdGhvdXQgc2V0dGluZyBwZXItVlBOIHZwbi1wb2xpdHkuIEl0IGRl cGVuZHMgb24gZWFjaCBvcGVyYXRvcidzIHNlcnZpY2UuDQoNClN0ZXBoYW5lIHByb3Bvc2VkIHRv IHVzZSBhcHBseS10ZW1wbGF0ZSwgYnV0IGl0IHN0aWxsIGNhbm5vdCBzb2x2ZSB0aGUgcHJvYmxl bS4gV2hlbiBlYWNoIFZQTiBhbHJlYWR5IGhhcyBhIGxhcmdlIG51bWJlciBvZiBzaXRlcyBhbmQg d2FudCB0byBjb25uZWN0IGVhY2ggb3RoZXIgZm9yIHRoZSBmaXJzdCB0aW1lLCBib3RoIFZQTnMg bXVzdCB1cGRhdGUgdGhlc2Ugc2l0ZXMgdG8gYXBwbHkgYXBwbHktdGVtcGxhdGUgb24gdGhlIGN1 cnJlbnQgbW9kZWwuDQoNCiANCg0KVGhhbmtzLA0KDQpLZW5pY2hpDQoNCiANCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRm Lm9yZyA8bWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZz4gXSBPbiBCZWhhbGYgT2YgUWluIFd1 DQoNClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDQsIDIwMTUgMTI6NDIgQU0NCg0KVG86IGwzc21A aWV0Zi5vcmcgPG1haWx0bzpsM3NtQGlldGYub3JnPiANCg0KQ2M6IGFkcmlhbkBvbGRkb2cuY28u dWsgPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPiANCg0KU3ViamVjdDogW0wzc21dIEwzU00g aW50ZXJpbSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24N Cg0KIA0KDQpIaSBhbGw6DQoNCiANCg0KIA0KDQpCZWxvdyBpcyB0aGUgaW5pdGlhbCB2ZXJzaW9u IG9mIGRyYWZ0IG1pbnV0ZXMgZm9yIFRodXJzZGF5IEwzU00gV0cgaW50ZXJpbSBzZXNzaW9uLg0K DQogDQoNClRoYW5rcyBEYW4gdG8gaGVscCB0YWtlIG1pbnV0ZXMuDQoNCiANCg0KRm9sa3MsIHBs ZWFzZSBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgY29ycmVjdGlvbi4NCg0KIA0KDQogDQoN Ci1RaW4NCg0KIA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCiANCg0KTDNTTSBXb3JraW5n IEdyb3VwIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nIA0KDQogDQoNClRodXJzZGF5IERlY2VtYmVy IDV0aCwgMjAxNS4gOGFtIEVhc3QgQ29hc3QgVGltZSAoTmV3IFlvcmspDQoNCiANCg0KIA0KDQpC TFVFIFNIRUVUDQoNCiANCg0KIA0KDQpOYW1lICAgICAgICAgICAgICAgICAgICB8IEFmZmlsaWF0 aW9uDQoNCiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst DQoNCiANCg0KQWRyaWFuIEZhcnJlbCAgICAgICAgICAgfCBPbGQgRG9nIENvbnN1bHRpbmcNCg0K IA0KDQpRaW4gV3UgICAgICAgICAgICAgICAgICB8IEh1YXdlaSBUZWNobm9sb2dpZXMNCg0KIA0K DQpTdGVwaGFuZSBMaXRrb3dza2kgICAgICB8IE9yYW5nZQ0KDQogDQoNCkx1aXMgVG9tb3Rha2kg ICAgICAgICAgIHwgVmVyaXpvbg0KDQogDQoNCkRhbmllbCBLaW5nICAgICAgICAgICAgIHwgT2xk IERvZyBDb25zdWx0aW5nDQoNCiANCg0KU3VzYW4gSGFyZXMgICAgICAgICAgICAgfCBIdWF3ZWkg VGVjaG5vbG9naWVzDQoNCiANCg0KU2NvdHQgTWFuc2ZpZWxkICAgICAgICAgfCBFcmljc3Nvbg0K DQogDQoNCkd1IFJvbmcgICAgICAgICAgICAgICAgIHwgQ2hpbmEgTW9iaWxlIA0KDQogDQoNCktl bmljaGkgT2dha2kgICAgICAgICAgIHwgS0RESQ0KDQogDQoNCkFpanVuIFdhbmcgICAgICAgICAg ICAgIHwgQ2hpbmEgVGVsZWNvbQ0KDQogDQoNClZpY3RvciBTYW50b3MgICAgICAgICAgIHwgRXJp Y3Nzb24NCg0KIA0KDQpJZ25hcyBCYWdkb25hcyAgICAgICAgICB8IA0KDQogDQoNCiANCg0KIA0K DQogDQoNCiANCg0KIA0KDQogDQoNCiANCg0KIA0KDQpNSU5VVEVTDQoNCiANCg0KIA0KDQoqIE1l dGluZyBsb2dpaXN0aWNzIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbDNz bS9TSnViMWFIVlFHT1FXNnJXaHRoWDBmQjhBYzggPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvbDNzbS9TSnViMWFIVlFHT1FXNnJXaHRoWDBmQjhBYzg+ICANCg0KIA0KDQoq IE1lZXRpbmcgbWF0ZXJpYWxzIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVy aW0vMjAxNS8xMi8wMy9sM3NtL3Byb2NlZWRpbmdzLmh0bWwgPGh0dHBzOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNS8xMi8wMy9sM3NtL3Byb2NlZWRpbmdzLmh0bWw+ICAN Cg0KIA0KDQoqIEV0aGVycGFkIGZvciBtaW51dGVzICh0aGlzIHBhZ2UpIGh0dHA6Ly9ldGhlcnBh ZC50b29scy5pZXRmLm9yZzo5MDAwL3AvbDNzbS1pbnRlcmltLTIwMTUtMTItMDMgPGh0dHA6Ly9l dGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAwL3AvbDNzbS1pbnRlcmltLTIwMTUtMTItMDM+IA0K DQogDQoNCiogSmFiYmVyIHVzaW5nIGwzc21AamFiYmVyLmlldGYub3JnIDxtYWlsdG86bDNzbUBq YWJiZXIuaWV0Zi5vcmc+IA0KDQogDQoNCiogQmx1ZSBzaGVldCBodHRwOi8vZXRoZXJwYWQudG9v bHMuaWV0Zi5vcmc6OTAwMC9wL2wzc20taW50ZXJpbS0yMDE1LTEyLTAzLWJsdWVzaGVldCA8aHR0 cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9sM3NtLWludGVyaW0tMjAxNS0xMi0w My1ibHVlc2hlZXQ+IA0KDQogDQoNCiANCg0KQWdlbmRhYQ0KDQogDQoNCi0gQWRtaW5pc3RyaXZp YSAoTm90ZSBXZWxsLCBldGMpLiBhDQoNCiANCg0KLSBJbnRyb2R1Y3Rpb24NCg0KIA0KDQotIE9w ZW4gSXNzdWVzIGZvciBZQU5HIERhdGEgTW9kZWwgZm9yIEwzVlBOc2VydmljZSBkZWxpdmVyeSAo ZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2Vtb2RlbCkNCg0KIA0KDQpvIE9wZW4gSXNzdWVz IGRpc2N1c3Npb24gYW5kIHJlc29sdXRpb27igJMgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv d2cvbDNzbS90cmFjL3JlcG9ydC8xIDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9sM3Nt L3RyYWMvcmVwb3J0LzE+IA0KDQogDQoNCiANCg0KRm9yIGEgZnVsbCBsaXN0IG9mIGlzc3VlcyBh bmQgcmVzb2x1dGlvbiBwcm9wb3NhbHMgcGxlYXNlIHNlZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1LzEyLzAzL2wzc20vc2xpZGVzL3NsaWRlcy1pbnRlcmlt LTIwMTUtbDNzbS0xLTIucGRmIDxodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRl cmltLzIwMTUvMTIvMDMvbDNzbS9zbGlkZXMvc2xpZGVzLWludGVyaW0tMjAxNS1sM3NtLTEtMi5w ZGY+IA0KDQogDQoNCiANCg0KSXNzdWUjMTogV2hlbiBjdXN0b21lci1uYXQtYWRkcmVzcyBpcyB1 c2VkDQoNCiANCg0KUmVzb2x1dGlvbiAjMTogIExlYWYgdXNlZCB3aGVuIE5BVCBpcyByZXF1aXJl ZCB0byBhY2Nlc3MgY2xvdWQgVlBOIGFuZCBjdXN0b21lciB3YW50cyB0byB1c2UgaXRzIG93bklQ IGFkZHJlc3MuIElmIHByb3ZpZGVyIHByb3ZpZGVzIHRoZSBwdWJsaWMgSVAsbm8gbmVlZCB0byB1 c2UgdGhlIGxlYWYNCg0KIA0KDQpTdGF0dXMgIzE6ICBDbG9zZWQgUGVuZGluZyBJLUQgdGV4dCBy ZXZpZXcuICAgDQoNCiANCg0KRGlzY3Vzc2lvbiBvbiAjMTogDQoNCiANCg0KIA0KDQpBaWp1biBh c2tzIGZvciBtb3JlIGRlc2NyaXB0aW9uIGluIHRoZSBZQU5HIG1vZGVsIGl0c2VsZg0KDQogDQoN ClN0ZXBoYW5lIHNob3dzIGN1cnJlbnQgbW9kZWwNCg0KIA0KDQpBZ3JlZWQgT0sNCg0KIA0KDQog DQoNCklzc3VlIzIgOiBJZGVudGlmeSBsM3ZwbiBzdmMgdXNpbmcgaWQgb3IgbmFtZSBvciBib3Ro DQoNCiANCg0KUmVzb2x1dGlvbiAjMjogIElEIGlzIGEgc3RyaW5nLCBhcyBwZXIgb3RoZXIgcHJv cGVydGllcyBpbiB0aGUgbW9kZWwNCg0KIA0KDQpTdGF0dXMgIzI6IENsb3NlZA0KDQogDQoNCkRp c2N1c3Npb24gb24gIzI6IA0KDQogDQoNCiANCg0KQWdyZWVkIE9LDQoNCiANCg0KIA0KDQpJc3N1 ZSMzOiBNIHRvIE4gYXZhaWxhYmlsaXR5IHN1cHBvcnQNCg0KIA0KDQpSZXNvbHV0aW9uICMzOiBN b2RlbGluZyBzaXRlcyB1c2luZyBhIGxpc3Qgd2l0aCBhIHByaW9yaXR5LCBzbyBpbmNsdWRlIGFj Y2VzcyBsaXN0IHdpdGggYSBwcmlvcml0eS4NCg0KIA0KDQpTdGF0dXMgIzM6DQoNCiANCg0KRGlz Y3Vzc2lvbiBvbiAjMzogDQoNCiANCg0KIA0KDQpRaW4gd2FzIGFza2luZyB0aGF0IE0gdG8gTiBh dmFpbGFiaWxpdHkgaXMgc3VwcG9ydGVkIHdpdGggYWNjZXNzIGFuZCBwcmlvcml0eSBudW1iZXIu IA0KDQogDQoNClN0ZXBoYW5lIHN0YXRlZCB0aGlzIGlzIHN1cHBvdGVkLiBUaGlzIG5ldyBwcm9w b3NhbCBhbHNvIHN1cHBvcnRzIG11bHRpcGxlIHNpdGVzLCBhcyBhIGxpc3QuDQoNCiANCg0KUWlu IGFsc28gYXNrZWQgaWYgR3JvdXAgSS1EIHdhcyBubyBsb25nZXIgbmVlZGVkLCB3aGljaCBpdCBp cyBub3QuIEFsc28gZ29vZCBzb2x1dGlvbiBzdXBwb3J0ZWQgYnkgb3RoZXIgb3BlcmF0b3JzLg0K DQogDQoNClN0ZXBoYW5lIGFza2VkIGlmIGZvdXIgcHJpb3JpdGllcyB3YXMgZW5vdWdoLCBvciBp ZiBtb3JlIHdlcmUgbmVlZGVkLiANCg0KIA0KDQogDQoNClJlOiBDb250YWluZXJzL1Byb3BlcnRp ZXMgZm9yIE5ldHdvcmsgQWNjZXNzIENvbmZpZ3VyYXRpb24gLSBDb25jbHVzaW9ucz8NCg0KIA0K DQogDQoNCm8gTG9jYXRpb24gLSBEaWZmZXJlbnQgc2l0ZSBJLUQ/DQoNCiANCg0KbyBRb1MgUG9s aWN5IC0gUGVyIG5ldHdvcmsgYWNjZXNzIGxpbmssIG9yIHNpdGUgaW5mb3JtYXRpb24/IFdvdWxk IFFvUyAoY29zdCkgYmUgZGlmZmVyZW50IHBlciBhY2Nlc3NsaW5rIG9yIHNpdGU/IEV4YW1wbGUg b2YgUHJpbWFyeSBhbmQgQmFja3VwIGxpbmtzIGdpdmVuLiANCg0KIA0KDQpvIEJhbmR3aWR0aCAt IE1vdmVkIHRvIGFjY2VzcyBsaW5rIGdyb3VwIA0KDQogDQoNCm8gTWF4aW11bSBSb3V0ZXMgLSAN Cg0KIA0KDQpTZWN1cml0eSwgcm91dGluZywgYW5kIHNlcnZpY2VzIGFyZSBkdXBsaWNhdGVkIHdp dGggaW5oZXJpdGFuY2UNCg0KIA0KDQogDQoNCiANCg0KSXNzdWUjNDogc2l0ZS1zZXJ2aWNlLWNs b3VkIGFjY2VzcyBhcyBncm91cGluZw0KDQogDQoNClJlc29sdXRpb24gIzQgQWxyZWFkeSByZXNp bHZlZCBhcyBhIHNlcGFyYXRlIGdyb3VwaW5nDQoNCiANCg0KU3RhdHVzICM0OiBDbG9zZWQNCg0K IA0KDQpEaXNjdXNzaW9uIG9uICM0OiANCg0KIA0KDQogDQoNCklzc3VlIzU6IE11bHRpY2FzdCBz dXBwb3J0IGFzIHJhaXNlZCBieSBFcmljIFJvc2VuDQoNCiANCg0KUmVzb2x1dGlvbiAjNTogOiBO ZXcgInByb3ZpZGVyIG1hbmFnZWQiIHByb3BlcnR5LCBhbmQgaW4gU2l0ZSBQcm9wZXJ0aWVzICJw cm9wZXJ0eS10eXBlIiAgYWRkZWQNCg0KIA0KDQpTdGF0dXMgIzU6IFNvbHV0aW9uIHByb3Bvc2Vk LiANCg0KIA0KDQpEaXNjdXNzaW9uIG9uICM1OiANCg0KIA0KDQogDQoNClN0ZXBoYW5lIHdpbGwg cHJvdmlvZGUgbmV3IHByb3BlcnR5IHByb3Bvc2FscyB3aWxsIGJlIHByb3ZpZGVkIHRvIEVyaWMg Zm9yIHJldmlldy4gDQoNCiANCg0KIA0KDQpJc3N1ZSM2OiBJbnZlbnRvcnkgb3BlcmF0aW9uYWwg c3RhdGUNCg0KIA0KDQpSZXNvbHV0aW9uICM2OiBJbmNsdWRlIGEgbmV3IGNvbnRhaW5lciBmb3Ig aW52ZW50b3J5IHN0YXRlLCBvciBhbiBSUEMgY2FsbCAoc2l0dGluZyBhYm92ZSB0aGUgc2Vydmlj ZSBvcmNoZXN0cmF0b3IpIHRvIHJldHJpZXZlIGludmVudG9yeSBzdGF0ZS4gDQoNCiANCg0KU3Rh dHVzICM2OiBOZWVkIHRvIHByb3Bvc2UgdG8gdGhlIFdHIGFuZCBhZ3JlZSBzb2x1dGlvbi4NCg0K IA0KDQpEaXNjdXNzaW9uIG9uICM2OiANCg0KIA0KDQogDQoNCkx1aXMgYXNrZWQgd291bGQgdGhp cyBpbmZvIGJlIGNvbGxlY3RlZCBmcm9tIHByb3Zpc2lvbiBzdGF0ZT8gU3RlcGhhbmUgc3VnZ2Vz dGVkIHRoaXMgd291bGQgbm90IGJlIGF2YWlsaWJsZS4gDQoNCiANCg0KQWRyaWFuIG9ic2VydmVk IHRoYXQgdGhlIGNvZGUgdXNlZCB0byBjb252ZXJ0IHRoZSBtb2RlbCBpbnRvIGEgc2VydmljZSBy ZXF1ZXN0IG1heSBub3QgdXRpbGlzZSB0aGlzIGludmVudG9yeSBpbmZvcm1hdGlvbiBjYXBhYmls aXR5LiBTdWUgbWVudGlvbmVkIHRoYXQgb3RoZXJzIGhhdmUgbWVudGlvbmVkIGJ5IGEgdmVuZG9y IHRoYXQgaXQgd291bGQgYmUgdXNlZnVsIHRvIGhhdmUgdGhlIGFiaWxpdHkgdG8gY29uZmlndXJl IGludmVudG9yeSBzdGF0ZS4gVGhpcyBzaG91bGQgYmUgY2xhcmlmaWVkIGJ5IHRoZSBvcGVyYXRv cnMuIA0KDQogDQoNCiANCg0KU3RlcGhhbmUgdG8gdGFrZSBwcm9wb3NhbHMgdG8gbGlzdCBhbmQg YXNrIGFueW9uZSB3aG8gaXMgaW50ZXJlc3RlZCBpbiBoYXZpbmcgdGhlIGZlYXR1cmUgdG8gc3Vn Z2VzdCB0ZXh0Lg0KDQogDQoNCiANCg0KIA0KDQpJc3N1ZSM3OiBHZW5lcmljIFZBUyAtIGRvIHdl IG5lZWQgdG8gY3JlYXRlIGEgZ2VuZXJpYyBWQVMgY29udGFpbmVyIGFzIFZBUyBhcmUgcG9wdWxh ciBpbiBMM1ZQTnM/DQoNCiANCg0KUmVzb2x1dGlvbiAjNzogU2VwYXJhdGUgZnJvbSBMM1NNDQoN CiANCg0KU3RhdHVzICM3OiBDbG9zZWQNCg0KIA0KDQpEaXNjdXNzaW9uIG9uICM3OiANCg0KIA0K DQogDQoNCkd1IFJvbmcgaGlnaGxpZ2h0ZWQgR2VuZXJpYyBWQVMgbW9kZWwgd2hpY2ggd2FzIHBy ZXNlbnRlZCBhdCBJRVRGIDk0LiANCg0KIA0KDQogDQoNCklzc3VlIzg6IFdobyBrZWVwcyBzaXRl IGxvY2F0aW9uaW5mb3JtYXRpb24/DQoNCiANCg0KUmVzb2x1dGlvbiAjODogVGV4dCBoYXMgYmVl biBmaXhlZA0KDQogDQoNClN0YXR1cyAjODogQ2xvc2VkDQoNCiANCg0KRGlzY3Vzc2lvbiBvbiAj ODogDQoNCiANCg0KICAgIA0KDQogDQoNCklzc3VlIzk6IERvIHdlIG5lZWQgdG8gbW9kZWwgdHJh bnNwb3J0IGNvbnN0cmFpbnRzLCBzdWNoIGFzOiBqaXR0ZXIsIGRpc2pvaW50LCBwYXRoIGRpdmVy c2l0eT8NCg0KIA0KDQpSZXNvbHV0aW9uICM5OiAgIFByb3Bvc2UgYSAidHJhbnNwb3J0LWNvbnN0 cmFpbnQiIGdyb3VwIHdpdGggImNvbnN0cmFpbnQtdHlwZSIsICJjb25zdHJhaW50LXZhbHVlIiBh bmQgImNvbnN0cmFpbnQtbGlzdCIgKGNvbXBvc2VkIG9mIHR5cGUgYW5kIHZhbHVlcykNCg0KIA0K DQpTdGF0dXMgIzk6IEF1dGhvcnMgdG8gcHJvcG9zZSB0aGUgcmVzb2x1dGlvbiBpbiB0aGUgSS1E IGFuZCBwcm92aWRlIHRvIHRoZSBXRw0KDQogDQoNCkRpc2N1c3Npb24gb24gIzk6ICAgIA0KDQog DQoNCiANCg0KIA0KDQpMdWlzIG1lbnRpb25lZCB0aGF0IHRoZXkgaGF2ZSBtdWx0aWNhc3QgdHJh bnNwb3J0IChtdWx0aXBsZSBzaXRlcykgYW5kIGJpLWRpcmVjdGlvbmFsIHRyYWZmaWMgYXBwbGlj YXRpb25zIChmaW5hbmNpYWwpIHRoYXQgd2lsbCByZXF1aXJlIHRyYW5zcG9ydCBjb25zdHJhaW50 cw0KDQogDQoNCiANCg0KRHVwbGljYXRlIHRyYW5zcG9ydCBjb25zdHJhaW50cyBmb3IgdW5pY2Fz dCBhbmQgbXVsdGljYXN0IHRvIGdpdmUgb3B0aW9ucyBmb3Igc2VwYXJhdGUgY29uZmlndXJhdGlv bi4NCg0KIA0KDQpLZWVwIHNpbmdsZSBsaXN0IGVudHJpZXMgZm9yIGVhY2ggc3JjL2RzdCBwYWly IGV2ZW4gaW4gdGhlIG11bHRpY2FzdCB2YXJpYW50Lg0KDQogDQoNCiANCg0KRE8gd2UgbmVlZCB0 byBzdXBwb3J0IG11bHRpcGxlIGNvbnN0cmFpbnRzIG9yIGp1c3QgaGF2ZSBhIHNpbmdsZSBjb21w b3NpdGUgKG9mIG11bHRpcGxlIGNvbnN0cmFpbnRzKSwgaGF2ZSB0aGUgYWJpbGl0eSB0byBzcGVj aWZ5IGEgY29uc3RyYWludC1saXN0Pw0KDQogDQoNCkFpanVuIHByZmVycyBsaXN0IG9mIGNvbnN0 cmFpbnRzIGFuZCBtZWV0aW5nIGFncmVlcyB0aGlzIGlzIE9LDQoNCiANCg0KIA0KDQpXaGF0IGNv bnN0cmFpbnRzIHRvIG9mZmVyPw0KDQogDQoNCkxhdGVuY3kNCg0KIA0KDQpQYXRoIGRpdmVyc3R5 DQoNCiANCg0KU2l0ZSBkaXZlcnN0eQ0KDQogDQoNCkppdHRlcg0KDQogDQoNCkNsYXNzIG9mIHNl cnZpY2Ugd2FzIHByb3Bvc2VkIGJ1dCByZWplY3RlZA0KDQogDQoNCiANCg0KTHVpcyBoaWdobGln aHRlZCB0aGV5IGhhdmUgYSBjdXJyZW50IGltcGxlbWVudGF0aW9uIHRoYXQgdXNlcyB0aGUgc2lt aWxhciBwcm9wb3NhbC4gTHVpcyBhbHNvIG1lbnRpb25lZCB0aGF0IHNpdGUgZGl2ZXJzaXR5IG1p Z2h0IGFsc28gYmUgcmVxdWlyZWQsIHdvdWxkIHRoaXMgYmUgYWNoaWV2YWJsZQ0KDQogDQoNCiAN Cg0KIA0KDQpJc3N1ZSMxMDogVlBOICJtZXJnaW5nIg0KDQogDQoNClJlc29sdXRpb24gIzEwOiAg ICANCg0KIA0KDQpTdGF0dXMgIzEwOg0KDQogDQoNCkRpc2N1c3Npb24gb24gIzEwOiAgICANCg0K IA0KDQogDQoNClZQTiBpcyBhIHBlciBzaXRlIHByb3BlcnR5LiANCg0KIA0KDQotIEEgc2l0ZSBj YW4gYmVsb25nIHRvbXVsdGlwbGUgVlBOcw0KDQogDQoNCi0gSG93IHRvIGhhbmRsZSBtZXJnaW5n IG9mIHR3byBWUE5zPw0KDQogDQoNCi0gSXMgdGhpcyBhbiBpc3N1ZSB0aGUgc2VydmljZSBtb2Rl bCBoYXMgdG8gZGVhbCB3aXRoPw0KDQogDQoNCiANCg0KSWYgVlBOIG1lcmdpbmcgaXMgcmVxdWly ZWQgdG8gYmUgc2VhbWxlc3MsIHRoZW4gdGhpcyB3b3VsZCBiZSBkZXZpY2Ugc3BlY2lmaWMgYW5k IG5vdCBzZXJ2aWNlIG1vZGVsIHJlbGF0ZWQuICANCg0KIA0KDQogDQoNCiJNZXJnaW5nIiBpcyBh IGNvbmZ1c2luZyB0ZXJtLiBUaGUgb2JqZWN0aXZlIGlzIE5PVCB0byBtZXJnZSBWUE4xIGFuZCBW UE4yLg0KDQogDQoNClRoZSBvYmplY3RpdmUgaXMgdG8gcHJvdmlkZSBhbiBleHRyYW5ldCBzbyB0 aGF0IHNvbWUgc2l0ZXMgaW4gVlBOMSBjYW4gY29ubmVjdCB0byBzb21lIHNpdGVzIGluIFZQTjIg Zm9yIHNvbWUgdHJhZmZpYy4NCg0KIA0KDQpUaGlzIGNhbiBiZSBzb2x2ZWQgdXNpbmcgYSBwZXIt c2l0ZSBwcm9wZXJ0eS4NCg0KIA0KDQogDQoNCkFjdGlvbjogTmVlZCB0byB1cGRhdGUgdGhpcyBp c3N1ZSB0byBtYWtlIGl0IGNsZWFyIHdoYXQgZnVuY3Rpb24gd2FzIGJlaW5nIGRpc2N1c3NlZCwg YWxzbyBTdGVwaGFuZSB3aWxsIHNlbmQgb3B0aW9ucyB0byB0aGUgd29ya2luZyBncm91cC0gbGlz dC4gDQoNCiANCg0KV2UgYXJlIHNwZWNpZmljYWxseSBsb29raW5nIGZvciBwZW9wbGUgd2hvIG9m ZmVyIGV4dHJhbmV0IGNvbm5lY3Rpb24gYmV0d2VlbiBzaXRlcyBmcm9tIGRpZmZlcmVudCBWUE5z DQoNCiANCg0KIA0KDQo9PSBPdGhlciBJc3N1ZXMgPT0gICAgDQoNCiANCg0KIA0KDQpNb2RlbGlu ZyBDdXN0b21lciBTcGVjaWZpYyBJbmZvDQoNCiANCg0KLSBDcmVhdGUgYXBwcm9waWF0ZSBjb250 YWluZXJzIGZvciBQcm92aWRlciBFZGdlIGFuZCBDdXN0b21lciBTaXRlIHJvdXRlcnMNCg0KIA0K DQotIFRoZSBjdXJyZW50ICBtb2RlbCBjb250YWlucyByb3V0aW5nIHBhcmFtZXRyZXMgdGhhdCBy ZWZlciB0byBDRSBhbmQgUEUgcmVsYXRpb25zaGlwcw0KDQogDQoNCi0gR2VuZXJhbCBhZ3JlZW1l bnQgaXMgcm91dGluZyBpbmZvIHNob3VsZCBiZSBzcGxpdCBhbmQgY3VycmVudCBwcm9wb3NhbCB3 aWxsIGJlIHNlbnQgdG8gdGhlIGxpc3QgZm9yIEtlbmljaGksIGFuZCB3b3JraW5nIGdyb3Vwcywg cmV2aWV3LiANCg0KIA0KDQogDQoNCj09IENvbmNsdXNpb25zID09DQoNCiANCg0KIA0KDQotIEEg bnVtYmVyIG9mIHJlc29sdXRpb25zIGhhdmUgYmVlbiBhZ3JlZWQgYW5kIHdpbGwgYmUgdXBkYXRl ZCBpbiB0aGUgSS1EDQoNCiANCg0KLSBDaGFpcnMgd291bGQgbGlrZSB0byBzZWUgcmV2aXNlZCBJ LUQgYmFzZWQgb24gdGhlIGFncmVlZCBwb2ludHMNCg0KIA0KDQotIFBsYW4gdG8gaGF2ZSBhbm90 aGVyIGludGVyaW0gY2FsbCBhdCB0aGUgZW5kIG9mIEphbnVhcnkgKDIwMTYpDQoNCiANCg0KLSBD aGFpcnMgdG8gYWRkIG5ldyB0cmFja2VyIGl0ZW1zLCBpbmNsdWRpbmcgc2VjdXJpdHkgZm9yIGZ1 dHVyZSBkaXNjdXNzaW9uLiANCg0KIA0KDQogDQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KTDNzbSBtYWlsaW5nIGxpc3QNCg0KTDNzbUBp ZXRmLm9yZyA8bWFpbHRvOkwzc21AaWV0Zi5vcmc+IA0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2wzc20gPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbDNzbT4gDQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KTDNzbSBtYWlsaW5nIGxpc3QNCg0KTDNzbUBpZXRmLm9yZyA8bWFpbHRvOkwz c21AaWV0Zi5vcmc+IA0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wz c20gPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbT4gDQoNCiANCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQogDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaQ0KDQogDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3JpemF0aW9uLg0KDQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBzaGFsbCBub3QgYmUg bGlhYmxlIGlmIHRoaXMgbWVzc2FnZSB3YXMgbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KDQpUaGFuayB5b3UuDQoNCiANCg0KIA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KIA0KDQpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kNCg0KIA0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXphdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJh bmNlIFRlbGVjb20gLSBPcmFuZ2Ugc2hhbGwgbm90IGJlIGxpYWJsZSBpZiB0aGlzIG1lc3NhZ2Ug d2FzIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQogDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkwzc20g bWFpbGluZyBsaXN0DQoNCkwzc21AaWV0Zi5vcmcgPG1haWx0bzpMM3NtQGlldGYub3JnPiANCg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtIDxodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20+IA0KDQogDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkwzc20gbWFpbGluZyBsaXN0DQoNCkwz c21AaWV0Zi5vcmcgPG1haWx0bzpMM3NtQGlldGYub3JnPiANCg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sM3NtIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2wzc20+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KTDNzbSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KTDNzbSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTDNzbSBtYWlsaW5nIGxpc3QN Ckwzc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNz bQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTDNz bSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbDNzbQ0K From nobody Wed Feb 24 21:01:20 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63ABA1AC41C for ; Wed, 24 Feb 2016 21:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 OwaGC_Qjn8wt for ; Wed, 24 Feb 2016 21:01:16 -0800 (PST) Received: from post-send.kddi.com (athena4.kddi.com [27.90.165.197]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBFF1A8892 for ; Wed, 24 Feb 2016 21:01:15 -0800 (PST) Received: from LTMC2121.kddi.com (LTMC2121.kddi.com [10.206.0.61]) by post-send.kddi.com (KDDI Mail) with ESMTP id 02F37120104; Thu, 25 Feb 2016 14:01:15 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2121.kddi.com with ESMTP; Thu, 25 Feb 2016 14:01:14 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id C67A74C005A; Thu, 25 Feb 2016 14:01:14 +0900 (JST) Received: from LTMC2151.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id BB5804C0058; Thu, 25 Feb 2016 14:01:14 +0900 (JST) Received: from LTMC2151.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u1P51EK8019175; Thu, 25 Feb 2016 14:01:14 +0900 Received: from LTMC2151.kddi.com.mid_32670733 (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id u1P4pDb8008838; Thu, 25 Feb 2016 13:51:14 +0900 X-SA-MID: 32670733 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Thu, 25 Feb 2016 13:51:13 +0900 From: "Ogaki, Kenichi" To: "'Qin Wu'" , , References: <11137_1452868271_569902AF_11137_18933_1_9E32478DFA9976438E7A22F69B08FF921683F2D0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <009a01d1518a$dccd16e0$966744a0$@kddi.com> <28946_1453107612_569CA99C_28946_1310_1_9E32478DFA9976438E7A22F69B08FF921683F60F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <000001d15266$38428380$a8c78a80$@kddi.com> <002c01d16d15$fb50c390$f1f24ab0$@kddi.com> In-Reply-To: Date: Thu, 25 Feb 2016 13:51:13 +0900 Message-ID: <018d01d16f88$2776fd80$7664f880$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5Bq8eqk2F/jjoJjePPJmqqbPofQJPFi+8Aw+DAN8BzQ7zqQKVjWu7AxyabOmehhEagA== Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Modeling a site with multiple subsites X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 05:01:19 -0000 Hi Qin, >Support subVPN case or multiple network accesses that is not for = multihoming? Not for multihoming from a site to a single VPN(or under a single = vpn-policy). The current model can only differentiate vpn-policy per sites. But, = there are many use cases to require vpn-policy per site-network-access. You can find the current limitation and use cases on the exchanges in = this thread. >I believe this issue is separated from what we discussed earlier about = extranet VPN policy. Yes, this is different issue. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu Sent: Thursday, February 25, 2016 12:57 PM To: Ogaki, Kenichi; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Kenichi: Can you clarify a little bit the objective of the following proposal? Support subVPN case or multiple network accesses that is not for = multihoming? I believe this issue is separated from what we discussed earlier about = extranet VPN policy. -Qin -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: L3sm [mailto:l3sm-bounces@ietf.org] =B4=FA=B1=ED = Ogaki, Kenichi =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C222=C8=D5 10:09 =CA=D5=BC=FE=C8=CB: stephane.litkowski@orange.com; l3sm@ietf.org =D6=F7=CC=E2: Re: [L3sm] Modeling a site with multiple subsites Hi Stephane and All, >>How to you differentiate multihoming from your subVPN case? they are=20 >>two different >things. >As I wrote, we just have to *duplicate* vpn-policy under=20 >site-network-access. When an operator's use case requires multiVPN,=20 >then vpn-policy should be under sites as the current model does. >When the other operator requires subVPN, vpn-policy should just be=20 >under site- network-access. It's sufficient to use these two cases = exclusively. Here is a minimum modification proposal to the current model in order to = use these two cases exclusively. Only if a vpn-policy is not defined directly under sites, we can define = it under site-network-access. If something is grammatically wrong in terms of YANG and XPATH = expression, could anyone correct me? ... container site-network-accesses { list site-network-access { uses site-vpn-policy { refine vpn-policy { when "not(../../../vpn-policy)"; } } ... } ... } ... Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Tuesday, January 19, 2016 12:05 PM To: stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi Stephane, >We cannot use site-network-access which is used for multihoming only. Why do we have to use site-network-access only for multihoming? This is = intuitively mapped to a logical access as you wrote. >How to you differentiate multihoming from your subVPN case? they are = two different things. As I wrote, we just have to *duplicate* vpn-policy under = site-network-access. When an operator's use case requires multiVPN, then = vpn-policy should be under sites as the current model does. When the other operator requires subVPN, vpn-policy should just be under = site-network-access. It's sufficient to use these two cases exclusively. >Could you provide more technical detail so I will be able to understand = what exactly you are trying to achieve ? Our existing commercial service allows the *logically* following = diagram. PE1, PE2 and PE3 can be VRFs inside a single physical PE, or may be = physically separate PEs. Same as CEs. L2SW can be QinQ sub-interfaces on = a single physical PE depending on the above case. Then, we may map each element like this. sites: A customer premises connected via QinQ (stag 100) sub-sites: A customer premises' layer 2 segment separated by .1Q (ctag = 10 or 20), a ctag segment can include multiple logical accesses with bgp = peer per logical access. For example, PE1 has a bgp peer with CE1, and = PE2 has a different bgp peer with CE2. In this case, when VPN X only talks to LAN X, we need subVPN inside = sub-sites. But, we can deal with a sub-sites as a sites for the = simplicity to minimally extend the current model. Even so, we still need = vpn-policy per site-network-access. +-----------------------------+ +------------------------------+ | | | | | /---\ ctag 10 | | ctag 10 /---\ | | VPN A-+ PE1 +--------+ | | +--------+ CE1 +-LAN A | | \---/ | | | | \---/ | | | | | | | | /---\ctag 10+-+----+ |stag 100| +----+-+ctag 10/---\ | | VPN B-+ PE2 +------+ L2SW +-+--------+-+ L2SW +------+ CE2 +-LAN B | | \---/ +-+----+ | | +----+-+ \---/ | | | | | | | | /---\ctag 20 | | | | ctag 20 /---\ | | VPN C-+ PE3 +--------+ | | +--------+ CE3 +-LAN C | | \---/ | | \---/ | | | | | +-----------------------------+ +------------------------------+ Central Office Customer Premises All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Monday, January 18, 2016 6:00 PM To: Ogaki, Kenichi; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi, We cannot use site-network-access which is used for multihoming only. How to you differentiate multihoming from your subVPN case ? they are = two different things. So I'm completely against using site-network-accesses as a subVPN can be = also multihomed ... > FYI, our commercial service honestly has a similar element as = sub-sites, corresponding to vlan, but we still allows multiple vpns and = bgp peers, each different vpn access per peer, within a single vlan. Could you provide more technical detail so I will be able to understand = what exactly you are trying to achieve ? Best Regards, Stephane -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Monday, January 18, 2016 01:55 To: LITKOWSKI Stephane SCE/OINIS; l3sm@ietf.org Subject: RE: [L3sm] Modeling a site with multiple subsites Hi Stephane, >Single "physical" access between SP and customer, but multiple = sub-accesses on top (VLAN, PPP sessions, or whatever ...), each one = pointing to a specific VPN. As you wrote above in the scenario a) and b), vpn-policy only have to be = controlled per logical access, equivalent to the site-network-access in = the current model. To solve the issue as simple as possible, it's = sufficient to duplicate vpn-policy under site-network-access. In these cases, a completely different conceptual element, sub-sites, is = not required. This must bring a complexity, and sometimes hard to be = understood, depending on operator's usecase.=20 Although we shouldn't discuss the device modelling, the granularity of = sub-sites corresponds to a VRF's one from the viewpoint of vpn-policy. = In this case, nobody intuitively imagines (sub-)sites from VRF, because = it's commonly in a single physical box. FYI, our commercial service honestly has a similar element as sub-sites, = corresponding to vlan, but we still allows multiple vpns and bgp peers, = each different vpn access per peer, within a single vlan. All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Friday, January 15, 2016 11:31 PM To: l3sm@ietf.org Subject: [L3sm] Modeling a site with multiple subsites [Creating another topic for better followup] =20 Today the model has the ability to create sites, a site can be = multihomed to the network thanks to the site-network-access sub-tree. =20 Now the question is how to we model such scenarios : =20 a) "SUBVPN case" : Single "physical" access between SP and = customer, but multiple sub-accesses on top (VLAN, PPP sessions, or = whatever .), each one pointing to a specific VPN. It is expected for the = customer to ensure flow separation (VRF lite, VLANs .). It's typically a = big company with a Hub site used where affiliates have dedicated = resources in the Hub site, and affiliates must not talk to each other or = even share resources. Note that I putted "physical" between quotes = because it can be a nested logical accesses . =20 =20 b) "INTER-AS option A like " case : this is the back to back VRF = case, as previously single "physical" access and multiple logical = accesses on top each one pointing to a separate VPN. I putted interAS, = but this can be "intra-AS" with iBGP back to back VRFs also (internal DC = for example) =20 c) What about option B ? Do we consider option B as a service ? I = would not be in favor of that. Option B setups are really particular in = term of design, security . So I would like to have option B out of = scope. =20 =20 Even if a) and b) are separated use cases from a service point of view, = these are similar in term of modeling. =20 Today we can model it has a collection of separated sites without any = relationship between each other. The other point is that we cannot = express any property of the "physical" attachment but there may few = (encryption ?). We can keep the model as it is with this limitation or = we can create site and sub-site hierarchy which as I already said may = complexify the reading and usability (IMO). It may look like this : =20 =A1=A4 Sites o Site-only-parameters : =A1=EC Location =A1=EC Diversity =A1=EC management =A1=EC Security o Specific-parameters : <- to be used only if there is no subsite. =A1=EC Vpn-policy =A1=EC Services =A1=EC Routing-protocols =A1=EC Site-network-accesses =A1=A4 .. o Sub-sites : <- to be used in case of sub sites present =A1=EC Specific-parameters : =A1=A4 Vpn-policy =A1=A4 Services =A1=A4 Routing-protocols =A1=A4 Site-network-accesses o . =20 I'm also wondering if bearer parameters must also be taken out in this = case and putted in the site-only-parameters.=20 The hierarchy becomes really complex here and I would like to keep it as = simple as possible. =20 =20 Would be good to have multiple feedbacks from the WG to see where the = consensus is. =20 =20 Orange logo =20 =20 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 =20 =20 =20 _________________________________________________________________________= ________________________________________________ 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 _______________________________________________ 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 _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Wed Feb 24 21:01:43 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403741ACD00 for ; Wed, 24 Feb 2016 21:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.048 X-Spam-Level: *** X-Spam-Status: No, score=3.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=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 wnpuh-Lq_--w for ; Wed, 24 Feb 2016 21:01:36 -0800 (PST) Received: from post-send.kddi.com (athena2.kddi.com [27.90.165.195]) by ietfa.amsl.com (Postfix) with ESMTP id 295831ACE85 for ; Wed, 24 Feb 2016 21:01:36 -0800 (PST) Received: from LTMC2122.kddi.com (LTMC2122.kddi.com [10.206.0.63]) by post-send.kddi.com (KDDI Mail) with ESMTP id 9EFF9E00FB; Thu, 25 Feb 2016 14:01:35 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2122.kddi.com with ESMTP; Thu, 25 Feb 2016 14:01:35 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 78D904C005A; Thu, 25 Feb 2016 14:01:35 +0900 (JST) Received: from LTMC2153.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id 6D6DF4C0058; Thu, 25 Feb 2016 14:01:35 +0900 (JST) Received: from LTMC2153.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2153.kddi.com with ESMTP id u1P51ZVr016141; Thu, 25 Feb 2016 14:01:35 +0900 Received: from LTMC2153.kddi.com.mid_60040474 (localhost.localdomain [127.0.0.1]) by LTMC2153.kddi.com with ESMTP id u1P4pVO7005831; Thu, 25 Feb 2016 13:51:31 +0900 X-SA-MID: 60040474 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Thu, 25 Feb 2016 13:51:30 +0900 From: "Ogaki, Kenichi" To: "'Aijun Wang'" <13301168517@189.cn>, , References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> <004101d16e97$e0692800$a13b7800$@kddi.com> <002d01d16e9f$88e66130$9ab32390$@cn> <006701d16ec0$1063fee0$312bfca0$@kddi.com> <004301d16ec8$270d9090$7528b1b0$@cn> <008401d16ede$20cee4c0$626cae40$@kddi.com> <004201d16f6f$22023cc0$6606b640$@cn> <015201d16f7c$3725b160$a5711420$@kddi.com> <008001d16f80$782b3690$6881a3b0$@cn> In-Reply-To: <008001d16f80$782b3690$6881a3b0$@cn> Date: Thu, 25 Feb 2016 13:51:30 +0900 Message-ID: <018e01d16f88$3194dd50$94be97f0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+JsdlYZ7cvi/Fz8JTONaqj4LvoQKs2aO/AYjUCCUDWny42AHbJwT5AVTH19oBa6ZKmwJ6yFzNARuYlCYCFgz0651T++Pg Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 05:01:41 -0000 Hi Aijun, >[Aijun Wang]: Within current Yang model, the customer need still to = configure both sites and vpn-svc. If we use the site template, some = parameters=20 >that keep unchanged need not be input by customer. I'm saying the case just adding a new site to already existing vpn. Does = this require to configure the vpn?=20 >[Aijun Wang]: If the customer does not input these information, how can = you get it from "op-state"? The operation state should consider only=20 >the real time information that gathered from the underlying network = dynamically. In my understanding, it's not only for real time information. I mean the = following one. https://mailarchive.ietf.org/arch/msg/l3sm/6zMiZSlcijda0ts_6NONdmwP3-E Thanks, Kenichi -----Original Message----- From: Aijun Wang [mailto:13301168517@189.cn]=20 Sent: Thursday, February 25, 2016 12:56 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Please see the comments inline, wish we can reach an agreement before = the interim meeting. :) -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Thursday, February 25, 2016 11:26 AM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, If we configure the relationship between vpn-svc and sites as follows, = we should remove corresponding vpn-policy under sites to avoid the = inconsistency. [Aijun Wang] Yes, we should redefine the vpn-policy as = site-prefix-policy, which defines only what prefix will be advertised by = this site, not the relationship among different sites. In this case, when we create new sites, we must configure both sites and = vpn-svc, and this bothers our customers. But, the current model structure only have to configure sites. Then, I = prefer the current one. [Aijun Wang]: Within current Yang model, the customer need still to = configure both sites and vpn-svc. If we use the site template, some = parameters that keep unchanged need not be input by customer. I don't object the sites list defined under vpn-svc as a *op-state*. [Aijun Wang]: If the customer does not input these information, how can = you get it from "op-state"? The operation state should consider only = the real time information that gathered from the underlying network = dynamically. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 10:52 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Based on our discussion, do you think the following proposal are = acceptable? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } =20 list sites{ leaf site-id leaf site-role leafref path "/l3vpn-svc/site-templates/site-template-id" = =20 } } list site-templates{ ...=20 } ... } -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Wednesday, February 24, 2016 4:34 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >Within the current Yang model, it is not loose coupled for the vpn and=20 >sites. Every site is associated with at least one vpn-policy entry. I wanted to mean by loose coupling that vpn and site should be = structurally at the same level. This means that a kind of graph = structure is better than a hierarchical structure. In a VPN service, it=E2=80=99s natural that a site must belong to at = least one vpn. >The reason that I prefer the "vpn-->site" structure to "site-->vpn"=20 >structure is that the majority of containers within lists "sites" are=20 >vpn-related, as you also confirmed this. >From the configuration viewpoint in the current model, the link = information between vpn and site can be configurable only in sites. = That's vpn-policy. This is reasonable to avoid the inconsistency in the case that both can = be configurable.=20 This information, which site belongs to which vpn, may be able to be = moved under vpn-svc as a list, but I don't think the necessity. It may = be useful to define the op-state under vpn-svc as discussed in issue#6. I agreed with the principle what you wrote, but I didn't carefully = discuss each container should be under vpn-svc or site. IMO, if any container is placed inappropriately, we should just move it = to the appropriate place. It's different problem from the model = structure discussion. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 2:57 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Within the current Yang model, it is not loose coupled for the vpn and = sites. Every site is associated with at least one vpn-policy entry.=20 The reason that I prefer the "vpn-->site" structure to "site-->vpn" = structure is that the majority of containers within lists "sites" are = vpn-related, as you also confirmed this. Then it is not enough in = current Yang model to correlate only the "vpn-policy" container to = different vpn id. And on the other way, we can also use the site-template to lessen the = burden of the customer configuration, as that done in current Yang = model. -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 12:59 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. > >[KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. >For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. >Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. >In that sense, I basically prefer the current model. >[Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. >There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement? If a physical customer site connects to two different vpns in this case, = the customer must input or update the information about the (physical) = site duplicately per vpn-svc. This may cause misconfiguration and bother = our customers. Another concern is the inconsistency with accounting/charging model, = when an operator charges the fee for physical access, it becomes = inconsistent with the charging model. When we does a traffic accounting = not only for logical access per vpn, but also for physical access, we = must always take care of the existence of different vpn-svc with the = same physical access in order to trigger a polling traffic counter of = the interface on PE. I understand it depends on each operator's service definition, vpn = specific or site specific, as Stephane wrote. To accommodate these different requirements, I think the loose coupled = model between the components, vpn and site, seems better. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 10:06 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Please see the reply inline. Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network = Research and Operation Support Department -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 8:11 AM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, See comments inline, please. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 18, 2016 1:12 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Stephane and Ogaki: =20 I suggested we put the "extranet-vpn-policy" under the list "vpn-svc" = directly, not in the container "vpn-policy" that is now under the list = "sites" in current model.=20 [KO]Like this? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } ... } ... } [Aijun Wang]: Yes. This can solve the initial scenario that proposed by Kenichi at the = beginning of our discussion. When the orchestrator receives the = information defined in "extranet-vpn-policy", it can allocate new = route-target for the involved VPNs and set them in the configuration = stanza of each router. =20 For the relationship of list "vpn-svc" and list "sites", I still suggest = we put the list "site" under the "vpn-svc", the reason for doing this is = as below: 1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. [KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. In that sense, I basically prefer the current model. [Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement?=20 2. The attributes of "sites", such as "maximum-routes", "security", = "service", "routing-protocols","site-netwok-accesses" etc. are all = service/site role related, that is to say, if the site role changed, all = of these attributed may be changed accordingly. [KO] I basically agree. The attributes tied to a whole vpn and globally = applied to all the sites under the vpn should be defined with the vpn = definition. 3.For container "vpn policy" that under list "sites" in current model, = there are two information defined, one is "filter" for prefix filtering, = another is "site-role". I suggest we split it, put the leaf "site-role" = under leaf "site-id" directly, and change the name of "vpn-policy" to = "site-prefix-policy".=20 =20 The final suggest structure of the L3VPN yang model will be look like = the bellow, I underline the changed positions from the current l3vpn = Yang Model =20 Container L3vpn-svc List vpn-svc Leaf vpn-id Leaf customer-name Leaf topology List extranet-vpn-policy Container cloud-access List multicast Leaf mpls List transport-contraints =20 List sites Leaf site-id Leaf site-role leaf apply-template ... ... ... ... Container managent Container site-prefix-policy Container maximum-routes Container security ... ... ... ... Site-network-access=20 =20 =20 Whether is it more reasonable?=20 =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute=20 Network Research and Operation Support Department =20 =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 18, 2016 9:08 AM To: l3sm@ietf.org Subject: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday = L3SM interim session =20 Hi Stephane and All, =20 As for issue #10 itself, the following solution can be acceptable for = us. =20 >One proposal could be to not call this VPN policy, but creating a >container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). =20 What model is in your mind? I can't see what ""extranet-vpn-policy" at = vpn" means. Like this? =20 ... 1 VPN1 VPN2 ... =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of stephane.litkowski@orange.com = =20 Sent: Monday, December 07, 2015 11:45 PM To: Ogaki, Kenichi; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi Kenichi, =20 Regarding your proposal of having a simple VPN policy in the vpn-svc = container, I do see an issue. One of the key point of the VPN policy is = to express the role of the site in the target VPN topology. If we do a vpn policy at VPN level, we cannot anymore describe site = roles in the target VPN which causes an issue. In an ideal world where all VPNs are any to any, the site role is always = the same and there is no issue, but let's think about someone trying to = use the vpn-policy (at vpn level) to connect to a Hub & Spoke VPN, how = do you deduce the roles of the sites ? =20 One proposal could be to not call this VPN policy, but creating a = container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). This means that the usage is really limited to "simple" = extranet-vpns and it does not replace nor compete with the VPN policy at = site level. =20 Could it be a good compromise ? =20 Stephane =20 =20 -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com = ] Sent: Saturday, December 05, 2015 06:23 To: LITKOWSKI Stephane SCE/OINIS; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear Stephane and All, =20 I don't say that sites *must* move under vpn-svc because I understand = stephane's use case. But we already have vpn-svc and some parameters under this are globally = applied to all the sites even in the current model. =20 It depends on operator's use case which is site-oriented or vpn-oriented = service. Our service is vpn-oriented, site has the native VPN. Then, I would just = like you to allow other global options to vpn-svc. =20 Thanks, Kenichi =20 -----Original Message----- From: stephane.litkowski@orange.com = = [mailto:stephane.litkowski@orange.com = ] Sent: Friday, December 04, 2015 8:17 PM To: Aijun Wang; 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi, =20 I'm against this proposal, as I do not want to create any dependency = between a particular VPN and a list of sites. A site can belong to multiple VPNs with any kind of topology, if we = attach the site to a single VPN, we come back to the notion of "native = VPN" we had at the beginning of the model which was hard to understand = and so was removed. =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Aijun Wang Sent: Friday, December 04, 2015 02:44 To: 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear all: =20 Can we put the list "sites" within the list "vpn-svc", and define the = general vpn policy for all sites that within the corresponding vpn = service instance? If doing so, some entries within the current list "sites" can also be = dragged out for general usual purposes, for example, "maximum-routes", = "security" etc. These parameters are often all same for every site = within one VPN service instance.=20 =20 If some sites have special requirements, we can achieve this by using = some special "site-vpn-policy" within the corresponding site definition. Is this more acceptable for customers? =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute Intelligent = Network Product Line =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Ogaki, Kenichi Sent: Friday, December 04, 2015 9:02 AM To: 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear All, =20 It was good having discussion. =20 As for issue#10, the objective and problem we discussed in the meeting = as follows. =20 The objective is to provide per-VPN extranet service which connects two = different VPNs (e.g. VPN1 and VPN2). It means that any sites in VPN1 can = access to any sites in VPN2. The problem is that the current model must update vpn-policy under all = the sites belong to these two VPNs in order to offer this service. = Especially when this model is used as a customer self-control API, it's = not good idea to require customers to update the information of all the = sites. (It's not abstracted way, a service model should provide what the = consumer wants, not how.) If a service or customer requires to control = per-site vpn-policy, that of current model should be used without = setting per-VPN vpn-polity. It depends on each operator's service. Stephane proposed to use apply-template, but it still cannot solve the = problem. When each VPN already has a large number of sites and want to = connect each other for the first time, both VPNs must update these sites = to apply apply-template on the current model. =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Qin Wu Sent: Friday, December 04, 2015 12:42 AM To: l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: [L3sm] L3SM interim meeting minutes on Thursday L3SM interim = session =20 Hi all: =20 =20 Below is the initial version of draft minutes for Thursday L3SM WG = interim session. =20 Thanks Dan to help take minutes. =20 Folks, please let us know if you have any correction. =20 =20 -Qin =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =20 L3SM Working Group Virtual Interim Meeting=20 =20 Thursday December 5th, 2015. 8am East Coast Time (New York) =20 =20 BLUE SHEET =20 =20 Name | Affiliation =20 ------------------------+----------------------------------------------- ------------------------+- =20 Adrian Farrel | Old Dog Consulting =20 Qin Wu | Huawei Technologies =20 Stephane Litkowski | Orange =20 Luis Tomotaki | Verizon =20 Daniel King | Old Dog Consulting =20 Susan Hares | Huawei Technologies =20 Scott Mansfield | Ericsson =20 Gu Rong | China Mobile=20 =20 Kenichi Ogaki | KDDI =20 Aijun Wang | China Telecom =20 Victor Santos | Ericsson =20 Ignas Bagdonas |=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 MINUTES =20 =20 * Meting logiistics = https://mailarchive.ietf.org/arch/msg/l3sm/SJub1aHVQGOQW6rWhthX0fB8Ac8 = = =20 =20 * Meeting materials = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/proceedings.html= = =20 =20 * Etherpad for minutes (this page) = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03 = =20 =20 * Jabber using l3sm@jabber.ietf.org =20 =20 * Blue sheet = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03-bluesheet = = =20 =20 =20 Agendaa =20 - Administrivia (Note Well, etc). a =20 - Introduction =20 - Open Issues for YANG Data Model for L3VPNservice delivery = (draft-ietf-l3sm-l3vpn-servicemodel) =20 o Open Issues discussion and resolution=E2=80=93 = http://trac.tools.ietf.org/wg/l3sm/trac/report/1 = =20 =20 =20 For a full list of issues and resolution proposals please see: = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/slides/slides-in= terim-2015-l3sm-1-2.pdf = =20 =20 =20 Issue#1: When customer-nat-address is used =20 Resolution #1: Leaf used when NAT is required to access cloud VPN and = customer wants to use its ownIP address. If provider provides the public = IP,no need to use the leaf =20 Status #1: Closed Pending I-D text review. =20 =20 Discussion on #1:=20 =20 =20 Aijun asks for more description in the YANG model itself =20 Stephane shows current model =20 Agreed OK =20 =20 Issue#2 : Identify l3vpn svc using id or name or both =20 Resolution #2: ID is a string, as per other properties in the model =20 Status #2: Closed =20 Discussion on #2:=20 =20 =20 Agreed OK =20 =20 Issue#3: M to N availability support =20 Resolution #3: Modeling sites using a list with a priority, so include = access list with a priority. =20 Status #3: =20 Discussion on #3:=20 =20 =20 Qin was asking that M to N availability is supported with access and = priority number.=20 =20 Stephane stated this is suppoted. This new proposal also supports = multiple sites, as a list. =20 Qin also asked if Group I-D was no longer needed, which it is not. Also = good solution supported by other operators. =20 Stephane asked if four priorities was enough, or if more were needed.=20 =20 =20 Re: Containers/Properties for Network Access Configuration - = Conclusions? =20 =20 o Location - Different site I-D? =20 o QoS Policy - Per network access link, or site information? Would QoS = (cost) be different per accesslink or site? Example of Primary and = Backup links given.=20 =20 o Bandwidth - Moved to access link group=20 =20 o Maximum Routes -=20 =20 Security, routing, and services are duplicated with inheritance =20 =20 =20 Issue#4: site-service-cloud access as grouping =20 Resolution #4 Already resilved as a separate grouping =20 Status #4: Closed =20 Discussion on #4:=20 =20 =20 Issue#5: Multicast support as raised by Eric Rosen =20 Resolution #5: : New "provider managed" property, and in Site Properties = "property-type" added =20 Status #5: Solution proposed.=20 =20 Discussion on #5:=20 =20 =20 Stephane will proviode new property proposals will be provided to Eric = for review.=20 =20 =20 Issue#6: Inventory operational state =20 Resolution #6: Include a new container for inventory state, or an RPC = call (sitting above the service orchestrator) to retrieve inventory = state.=20 =20 Status #6: Need to propose to the WG and agree solution. =20 Discussion on #6:=20 =20 =20 Luis asked would this info be collected from provision state? Stephane = suggested this would not be availible.=20 =20 Adrian observed that the code used to convert the model into a service = request may not utilise this inventory information capability. Sue = mentioned that others have mentioned by a vendor that it would be useful = to have the ability to configure inventory state. This should be = clarified by the operators.=20 =20 =20 Stephane to take proposals to list and ask anyone who is interested in = having the feature to suggest text. =20 =20 =20 Issue#7: Generic VAS - do we need to create a generic VAS container as = VAS are popular in L3VPNs? =20 Resolution #7: Separate from L3SM =20 Status #7: Closed =20 Discussion on #7:=20 =20 =20 Gu Rong highlighted Generic VAS model which was presented at IETF 94.=20 =20 =20 Issue#8: Who keeps site locationinformation? =20 Resolution #8: Text has been fixed =20 Status #8: Closed =20 Discussion on #8:=20 =20 =20 =20 Issue#9: Do we need to model transport constraints, such as: jitter, = disjoint, path diversity? =20 Resolution #9: Propose a "transport-constraint" group with = "constraint-type", "constraint-value" and "constraint-list" (composed of = type and values) =20 Status #9: Authors to propose the resolution in the I-D and provide to = the WG =20 Discussion on #9: =20 =20 =20 =20 Luis mentioned that they have multicast transport (multiple sites) and = bi-directional traffic applications (financial) that will require = transport constraints =20 =20 Duplicate transport constraints for unicast and multicast to give = options for separate configuration. =20 Keep single list entries for each src/dst pair even in the multicast = variant. =20 =20 DO we need to support multiple constraints or just have a single = composite (of multiple constraints), have the ability to specify a = constraint-list? =20 Aijun prfers list of constraints and meeting agrees this is OK =20 =20 What constraints to offer? =20 Latency =20 Path diversty =20 Site diversty =20 Jitter =20 Class of service was proposed but rejected =20 =20 Luis highlighted they have a current implementation that uses the = similar proposal. Luis also mentioned that site diversity might also be = required, would this be achievable =20 =20 =20 Issue#10: VPN "merging" =20 Resolution #10: =20 =20 Status #10: =20 Discussion on #10: =20 =20 =20 VPN is a per site property.=20 =20 - A site can belong tomultiple VPNs =20 - How to handle merging of two VPNs? =20 - Is this an issue the service model has to deal with? =20 =20 If VPN merging is required to be seamless, then this would be device = specific and not service model related. =20 =20 =20 "Merging" is a confusing term. The objective is NOT to merge VPN1 and = VPN2. =20 The objective is to provide an extranet so that some sites in VPN1 can = connect to some sites in VPN2 for some traffic. =20 This can be solved using a per-site property. =20 =20 Action: Need to update this issue to make it clear what function was = being discussed, also Stephane will send options to the working group- = list.=20 =20 We are specifically looking for people who offer extranet connection = between sites from different VPNs =20 =20 =3D=3D Other Issues =3D=3D =20 =20 =20 Modeling Customer Specific Info =20 - Create appropiate containers for Provider Edge and Customer Site = routers =20 - The current model contains routing parametres that refer to CE and PE = relationships =20 - General agreement is routing info should be split and current proposal = will be sent to the list for Kenichi, and working groups, review.=20 =20 =20 =3D=3D Conclusions =3D=3D =20 =20 - A number of resolutions have been agreed and will be updated in the = I-D =20 - Chairs would like to see revised I-D based on the agreed points =20 - Plan to have another interim call at the end of January (2016) =20 - Chairs to add new tracker items, including security for future = discussion.=20 =20 =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 _______________________________________________ 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 _______________________________________________ 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 From nobody Wed Feb 24 22:56:08 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FBE1A896C for ; Wed, 24 Feb 2016 22:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.048 X-Spam-Level: *** X-Spam-Status: No, score=3.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=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 b_22mjeo_AL4 for ; Wed, 24 Feb 2016 22:56:01 -0800 (PST) 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 642261A8943 for ; Wed, 24 Feb 2016 22:55:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEZ04450; Thu, 25 Feb 2016 06:55:56 +0000 (GMT) Received: from LHREML701-CAH.china.huawei.com (10.201.5.93) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 06:55:55 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 06:55:54 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 14:55:48 +0800 From: Qin Wu To: Aijun Wang <13301168517@189.cn>, "'Ogaki, Kenichi'" , "stephane.litkowski@orange.com" , "l3sm@ietf.org" Thread-Topic: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session Thread-Index: AdFUzU8XUm4agADpQBu6GQYzpCj8XwVLtpZwARYqJIAAAejoAAAIIwmAAAIEnwAABX+QAAAkPvQAABRtUWAAAKws8AABXTxwAASFfbAAACkjkA== Date: Thu, 25 Feb 2016 06:55:47 +0000 Message-ID: References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> <004101d16e97$e0692800$a13b7800$@kddi.com> <002d01d16e9f$88e66130$9ab32390$@cn> <006701d16ec0$1063fee0$312bfca0$@kddi.com> <004301d16ec8$270d9090$7528b1b0$@cn> <008401d16ede$20cee4c0$626cae40$@kddi.com> <004201d16f6f$22023cc0$6606b640$@cn> <008101d16f80$b7dbafe0$27930fa0$@cn> <009201d16f98$802e5fd0$808b1f70$@cn> In-Reply-To: <009201d16f98$802e5fd0$808b1f70$@cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.208] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56CEA57D.006B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f9d4b28207e13f101c0388bd3ec1fd45 Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 06:56:06 -0000 T2theSwgaXQgbG9va3MgeW91IHR3ZWFrIHdoYXQgd2FzIHByb3Bvc2VkIGluIHRoZSBjdXJyZW50 IG1vZGVsLCBtb3ZlICJzaXRlcyIgbGlzdCB1bmRlciAidnBuLXN2YyIgbGlzdCBhbmQgYWRkIHNp dGUgcm9sZSBmb3IgZWFjaCBzaXRlIGJlbG9uZ2luZyB0byBzcGVjaWZpYyB2cG4uIEluIHRoZSBj dXJyZW50IG1vZGVsLCAgInNpdGUiIGxpc3QgaW4gcGFyYWxsZWwgd2l0aCAidnBuLXN2YyIgbGlz dCBpcyBwbGFjZWQgYXQgdGhlIHNhbWUgbGV2ZWwuDQoNCi1RaW4NCi0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCuWPkeS7tuS6ujogQWlqdW4gV2FuZyBbbWFpbHRvOjEzMzAxMTY4NTE3QDE4OS5jbl0g DQrlj5HpgIHml7bpl7Q6IDIwMTblubQy5pyIMjXml6UgMTQ6NDgNCuaUtuS7tuS6ujogUWluIFd1 OyAnT2dha2ksIEtlbmljaGknOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBp ZXRmLm9yZw0K5Li76aKYOiBSRTogW0wzc21dIElzc3VlICMxMCBSRTogTDNTTSBpbnRlcmltIG1l ZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGludGVyaW0gc2Vzc2lvbg0KDQpIaSwgUWlu Og0KDQpZZXMgd2UgY2FuLiBCZWNhdXNlIG9uZSBzaXRlIGhhcyBvbmx5IG9uZSByb2xlIGluIG9u ZSB2cG4uIElmIHRoaXMgc2l0ZSBiZWxvbmdzIHRvIGRpZmZlcmVudCB2cG4sIGFuZCBoYXMgZGlm ZmVyZW50IHJvbGUgaW4gZGlmZmVyZW50IHZwbiwgd2UgbmVlZCBqdXN0IGRlZmluZSBkaWZmZXJl bnQgdnBuIGlkLCBhbmQgaW5jbHVkZSB0aGUgcmVsZXZhbnQgc2l0ZXMgZGVmaW5pdGlvbiB0aGF0 IHdpbGwgZGVzY3JpYmUgdGhlIGRpZmZlcmVudCByb2xlIG9mIHRoZSBzYW1lIHNpdGUgaW4gaXQu DQoNCkJlc3QgUmVnYXJkcy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFp biBXdSBbbWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFy eSAyNSwgMjAxNiAxMjozNyBQTQ0KVG86IEFpanVuIFdhbmc7ICdPZ2FraSwgS2VuaWNoaSc7IHN0 ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W0wzc21dIElzc3VlICMxMCBSRTogTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVy c2RheSBMM1NNIGludGVyaW0gc2Vzc2lvbg0KDQpXaGVuIG9uZSBzaXRlIGJlbG9uZ3MgdG8gZGlm ZmVyZW50IFZQTnMgYW5kIGhhdmUgbXVsdGlwbGUgcm9sZXMsIGNhbiB5b3UgZGVzY3JpYmUgdGhl c2Ugcm9sZXMgaW4gdGhlIHNhbWUgc2VydmljZSBtb2RlbCB3aXRoIHlvdXIgcHJvcG9zYWw/DQoN Ci1RaW4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogQWlqdW4gV2FuZyBbbWFp bHRvOjEzMzAxMTY4NTE3QDE4OS5jbl0NCuWPkemAgeaXtumXtDogMjAxNuW5tDLmnIgyNeaXpSAx MTo1OA0K5pS25Lu25Lq6OiBRaW4gV3U7ICdPZ2FraSwgS2VuaWNoaSc7IHN0ZXBoYW5lLmxpdGtv d3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQrkuLvpopg6IFJFOiBbTDNzbV0gSXNzdWUg IzEwIFJFOiBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9uIFRodXJzZGF5IEwzU00gaW50 ZXJpbSBzZXNzaW9uDQoNCkhpLCBRaW46DQoNCk1heWJlIEkgZG8gbm90IGRlc2NyaWJlIHRoZSBz dHJ1Y3R1cmUgY2xlYXJseS4gSSBwdXQgdGhlIGxlYWYgInNpdGUtcm9sZSIgdW5kZXIgbGlzdHMg InNpdGVzIiwgd2hpY2ggaXMgbG9jYXRlZCB3aXRoaW4gdGhlIGxpc3QgdnBuLXN2Yy4gVGhlbiBp biBkaWZmZXJlbnQgdnBuLCB0aGUgc2l0ZS1yb2xlIGNhbiBiZSBkaWZmZXJlbnQuDQoNCkJlc3Qg UmVnYXJkcy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFpbiBXdSBbbWFp bHRvOmJpbGwud3VAaHVhd2VpLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNSwgMjAx NiAxMTo0OCBBTQ0KVG86IEFpanVuIFdhbmc7ICdPZ2FraSwgS2VuaWNoaSc7IHN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0wzc21dIElz c3VlICMxMCBSRTogTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NN IGludGVyaW0gc2Vzc2lvbg0KDQpBaWp1bjoNCkl0IGxvb2tzIGxpa2UgeW91IHByb3Bvc2UgdG8g cmVsb2NhdGUgc29tZSBwYXJhbWV0ZXJzIGluIHRoZSBtb2RlbCBzdHJ1Y3R1cmUuDQpCdXQgd2l0 aCB5b3VyIHByb3Bvc2FsLCBpdCBpcyBoYXJkIHRvIGRlc2NyaWJlIG9uZSBzaXRlIHBsYXlpbmcg ZGlmZmVyZW50IHJvbGUgaW4gZGlmZmVyZW50IFZQTiB3aGVuIG9uZSBzaXRlIGJlbG9uZ3MgdG8g bXVsdGlwbGUgVlBOcy4NCldpdGggVlBOLXBvbGljeSB1bmRlciBzaXRlIHByb3Bvc2VkIGluIHRo ZSBjdXJyZW50IG1vZGVsLCB5b3UgY2FuIGVhc2lseSBkZXNjcmliZSBvbmUgc2l0ZSB3aXRoIGRp ZmZlcmVudCByb2xlIGluIGVhY2ggVlBOIGFzIGZvbGxvd3M6DQoiDQogICAgY29udGFpbmVyIGwz dnBuLXN2YyB7DQogICAgICAgIGxpc3QgdnBuLXN2YyB7DQogICAgICAgICAgICBrZXkgdnBuLWlk Ow0KDQogICAgICAgICAgICBsZWFmIHZwbi1pZCB7DQogICAgICAgICAgICAgICAg4oCmDQogICAg ICAgICAgICB9DQogICAgICAgICAgICAuLi4NCiAgICAgICAgDQogICAgICAgICAgICBsaXN0IHNp dGVzew0KICAgICAgICAgICAgICBsZWFmIHNpdGUtaWQNCiAgICAgICAgICBjb250YWluZXIgdnBu LXBvbGljeSB7DQogICAgICAgICAgICBsaXN0IGVudHJpZXMgew0KICAgICAgICAgICAgICAgIGtl eSBpZDsNCiAgICAgICAgICAgICAgICBsZWFmIGlkIHsNCiAgICAgICAgICAgICAgICAgICAgICAg IHR5cGUgc3ZjLWlkOw0KICAgICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAg ICAgICAgICAgICAgICAgICAgICAiVW5pcXVlIGlkZW50aWZpZXIgZm9yDQogICAgICAgICAgICAg ICAgICAgICAgICAgIHRoZSBwb2xpY3kgZW50cnkuIjsNCiAgICAgICAgICAgICAgICB9DQpjb250 YWluZXIgdnBuIHsNCiAgICAgICAgICAgICAgICAgICAgbGVhZiB2cG4gew0KICAgICAgICAgICAg ICAgICAgICAgICAgdHlwZSBsZWFmcmVmIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBw YXRoICIvbDN2cG4tc3ZjL3Zwbi1zdmMvdnBuLWlkIjsNCiAgICAgICAgICAgICAgICAgICAgICAg IH0NCiAgICAgICAgICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0KICAgICAgICAgICAg ICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAiUmVmZXJl bmNlIHRvIGFuIElQVlBOLiI7DQogICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAg ICAgICAgbGVhZiBzaXRlLXJvbGUgew0KICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSBpZGVu dGl0eXJlZiB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgYmFzZSBzaXRlLXJvbGU7DQog ICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgICAgICBtYW5kYXRv cnkgdHJ1ZTsNCiAgICAgICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAg ICAgICAgICAgICAgICAgIlJvbGUgb2YgdGhlIHNpdGUgaW4gdGhlIElQVlBOLiI7DQogICAgICAg ICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAg ICAgICAgICAgICAgICJMaXN0IG9mIFZQTnMgdGhlIExBTiBpcyBhc3NvY2lhdGVkIHRvLiI7DQog ICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICB9DQogICAgICAgIH0NCiINCi1RaW4NCi0t LS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNl c0BpZXRmLm9yZ10g5Luj6KGoIEFpanVuIFdhbmcNCuWPkemAgeaXtumXtDogMjAxNuW5tDLmnIgy NeaXpSA5OjUyDQrmlLbku7bkuro6ICdPZ2FraSwgS2VuaWNoaSc7IHN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQrkuLvpopg6IFJlOiBbTDNzbV0gSXNzdWUgIzEw IFJFOiBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9uIFRodXJzZGF5IEwzU00gaW50ZXJp bSBzZXNzaW9uDQoNCkhpLCBPZ2FraToNCg0KQmFzZWQgb24gb3VyIGRpc2N1c3Npb24sIGRvIHlv dSB0aGluayB0aGUgZm9sbG93aW5nIHByb3Bvc2FsIGFyZSBhY2NlcHRhYmxlPw0KDQogICAgY29u dGFpbmVyIGwzdnBuLXN2YyB7DQogICAgICAgIGxpc3QgdnBuLXN2YyB7DQogICAgICAgICAgICBr ZXkgdnBuLWlkOw0KDQogICAgICAgICAgICBsZWFmIHZwbi1pZCB7DQogICAgICAgICAgICAgICAg 4oCmDQogICAgICAgICAgICB9DQogICAgICAgICAgICAuLi4NCiAgICAgICAgICAgIGxpc3QgZXh0 cmFuZXQtdnBuLXBvbGljeSB7DQogICAgICAgICAgICAgICAga2V5IHZwbi1pZDsNCiAgICAgICAg ICAgICAgICBsZWFmIHZwbi1pZCB7DQogICAgICAgICAgICAgICAgICAgIHR5cGUgc3ZjLWlkOw0K ICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgIH0NCiAgICAgICAgDQogICAgICAgICAgICBs aXN0IHNpdGVzew0KICAgICAgICAgICAgICBsZWFmIHNpdGUtaWQNCiAgICAgICAgICAgICAgbGVh ZiBzaXRlLXJvbGUNCiAgICAgICAgICAgICAgbGVhZnJlZiBwYXRoICIvbDN2cG4tc3ZjL3NpdGUt dGVtcGxhdGVzL3NpdGUtdGVtcGxhdGUtaWQiICAgIA0KICAgICAgICAgICAgfQ0KICAgICAgICB9 DQoNCiAgICAgICAgbGlzdCBzaXRlLXRlbXBsYXRlc3sNCiAgICAgICAgLi4uIA0KICAgICAgICB9 DQogICAgICAgIC4uLg0KICAgIH0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBPZ2FraSwg S2VuaWNoaQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA0OjM0IFBNDQpUbzog J0FpanVuIFdhbmcnOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtMM3NtXSBJc3N1ZSAjMTAgUkU6IEwzU00gaW50ZXJpbSBtZWV0aW5n IG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KSGkgQWlqdW4sDQoN Cj5XaXRoaW4gdGhlIGN1cnJlbnQgWWFuZyBtb2RlbCwgaXQgaXMgbm90IGxvb3NlIGNvdXBsZWQg Zm9yIHRoZSB2cG4gYW5kIA0KPnNpdGVzLiBFdmVyeSBzaXRlIGlzIGFzc29jaWF0ZWQgd2l0aCBh dCBsZWFzdCBvbmUgdnBuLXBvbGljeSBlbnRyeS4NCg0KSSB3YW50ZWQgdG8gbWVhbiBieSBsb29z ZSBjb3VwbGluZyB0aGF0IHZwbiBhbmQgc2l0ZSBzaG91bGQgYmUgc3RydWN0dXJhbGx5IGF0IHRo ZSBzYW1lIGxldmVsLiBUaGlzIG1lYW5zIHRoYXQgYSBraW5kIG9mIGdyYXBoIHN0cnVjdHVyZSBp cyBiZXR0ZXIgdGhhbiBhIGhpZXJhcmNoaWNhbCBzdHJ1Y3R1cmUuDQpJbiBhIFZQTiBzZXJ2aWNl LCBpdOKAmXMgbmF0dXJhbCB0aGF0IGEgc2l0ZSBtdXN0IGJlbG9uZyB0byBhdCBsZWFzdCBvbmUg dnBuLg0KDQoNCj5UaGUgcmVhc29uIHRoYXQgSSBwcmVmZXIgdGhlICJ2cG4tLT5zaXRlIiBzdHJ1 Y3R1cmUgdG8gInNpdGUtLT52cG4iIA0KPnN0cnVjdHVyZSBpcyB0aGF0IHRoZSBtYWpvcml0eSBv ZiBjb250YWluZXJzIHdpdGhpbiBsaXN0cyAic2l0ZXMiIGFyZSANCj52cG4tcmVsYXRlZCwgYXMg eW91IGFsc28gY29uZmlybWVkIHRoaXMuDQoNCj5Gcm9tIHRoZSBjb25maWd1cmF0aW9uIHZpZXdw b2ludCBpbiB0aGUgY3VycmVudCBtb2RlbCwgdGhlIGxpbmsgaW5mb3JtYXRpb24gYmV0d2VlbiB2 cG4gYW5kIHNpdGUgY2FuIGJlIGNvbmZpZ3VyYWJsZSBvbmx5IGluIHNpdGVzLiBUaGF0J3MgdnBu LXBvbGljeS4NClRoaXMgaXMgcmVhc29uYWJsZSB0byBhdm9pZCB0aGUgaW5jb25zaXN0ZW5jeSBp biB0aGUgY2FzZSB0aGF0IGJvdGggY2FuIGJlIGNvbmZpZ3VyYWJsZS4gDQpUaGlzIGluZm9ybWF0 aW9uLCB3aGljaCBzaXRlIGJlbG9uZ3MgdG8gd2hpY2ggdnBuLCBtYXkgYmUgYWJsZSB0byBiZSBt b3ZlZCB1bmRlciB2cG4tc3ZjIGFzIGEgbGlzdCwgYnV0IEkgZG9uJ3QgdGhpbmsgdGhlIG5lY2Vz c2l0eS4gSXQgbWF5IGJlIHVzZWZ1bCB0byBkZWZpbmUgdGhlIG9wLXN0YXRlIHVuZGVyIHZwbi1z dmMgYXMgZGlzY3Vzc2VkIGluIGlzc3VlIzYuDQoNCkkgYWdyZWVkIHdpdGggdGhlIHByaW5jaXBs ZSB3aGF0IHlvdSB3cm90ZSwgYnV0IEkgZGlkbid0IGNhcmVmdWxseSBkaXNjdXNzIGVhY2ggY29u dGFpbmVyIHNob3VsZCBiZSB1bmRlciB2cG4tc3ZjIG9yIHNpdGUuDQpJTU8sIGlmIGFueSBjb250 YWluZXIgaXMgcGxhY2VkIGluYXBwcm9wcmlhdGVseSwgd2Ugc2hvdWxkIGp1c3QgbW92ZSBpdCB0 byB0aGUgYXBwcm9wcmlhdGUgcGxhY2UuIEl0J3MgZGlmZmVyZW50IHByb2JsZW0gZnJvbSB0aGUg bW9kZWwgc3RydWN0dXJlIGRpc2N1c3Npb24uDQoNCg0KVGhhbmtzLA0KS2VuaWNoaQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFpanVuIFdhbmcNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh cnkgMjQsIDIwMTYgMjo1NyBQTQ0KVG86ICdPZ2FraSwgS2VuaWNoaSc7IHN0ZXBoYW5lLmxpdGtv d3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0wzc21dIElzc3Vl ICMxMCBSRTogTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGlu dGVyaW0gc2Vzc2lvbg0KDQpIaSwgT2dha2k6DQoNCldpdGhpbiB0aGUgY3VycmVudCBZYW5nIG1v ZGVsLCBpdCBpcyBub3QgbG9vc2UgY291cGxlZCBmb3IgdGhlIHZwbiBhbmQgc2l0ZXMuIEV2ZXJ5 IHNpdGUgaXMgYXNzb2NpYXRlZCB3aXRoIGF0IGxlYXN0IG9uZSB2cG4tcG9saWN5IGVudHJ5LiAN ClRoZSByZWFzb24gdGhhdCBJIHByZWZlciB0aGUgInZwbi0tPnNpdGUiIHN0cnVjdHVyZSB0byAi c2l0ZS0tPnZwbiIgc3RydWN0dXJlIGlzIHRoYXQgdGhlIG1ham9yaXR5IG9mIGNvbnRhaW5lcnMg d2l0aGluIGxpc3RzICJzaXRlcyIgYXJlIHZwbi1yZWxhdGVkLCBhcyB5b3UgYWxzbyBjb25maXJt ZWQgdGhpcy4gVGhlbiBpdCBpcyBub3QgZW5vdWdoIGluIGN1cnJlbnQgWWFuZyBtb2RlbCB0byBj b3JyZWxhdGUgb25seSB0aGUgInZwbi1wb2xpY3kiIGNvbnRhaW5lciB0byBkaWZmZXJlbnQgdnBu IGlkLg0KQW5kIG9uIHRoZSBvdGhlciB3YXksIHdlIGNhbiBhbHNvIHVzZSB0aGUgc2l0ZS10ZW1w bGF0ZSB0byBsZXNzZW4gdGhlIGJ1cmRlbiBvZiB0aGUgY3VzdG9tZXIgY29uZmlndXJhdGlvbiwg YXMgdGhhdCBkb25lIGluIGN1cnJlbnQgWWFuZyBtb2RlbC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IE9nYWtpLCBLZW5pY2hpIFttYWlsdG86a2Utb29nYWtpQGtkZGkuY29t XQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAxMjo1OSBQTQ0KVG86ICdBaWp1 biBXYW5nJzsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5vcmcNClN1 YmplY3Q6IFJFOiBbTDNzbV0gSXNzdWUgIzEwIFJFOiBMM1NNIGludGVyaW0gbWVldGluZyBtaW51 dGVzIG9uIFRodXJzZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCkhpIEFpanVuLA0KDQo+MS4g dGhlIHNlcnZpY2UgbW9kZWwgbXVzdCBiZSBzZXJ2aWNlIG9yaWVudGVkLiBJZiBvbmUgc2l0ZSBi ZWxvbmdzIHRvIHNldmVyYWwgdnBucywgd2Ugc2hvdWxkIGFjaGlldmUgdGhlIGdvYWwgYnkgZGVm aW5pbmcgc2V2ZXJhbCBzZXJ2aWNlIGluc3RhbmNlcy4NCj4NCj5bS09dIEkgY2FuJ3QgYWdyZWUg dGhpcy4gVGhlIGNhc2UgdGhhdCBhIHNpdGUgYmVsb25ncyB0byBtdWx0aXBsZSB2cG5zIGlzIGFs c28gYSB2ZXJ5IGNvbW1vbiBzZXJ2aWNlIHVzZSBjYXNlLCB0aGVuIHRoZSBzZXJ2aWNlIG1vZGVs IG11c3QgZGVzaWduIHRoaXMgYXBwcm9wcmlhdGVseS4NCj5Gb3IgZWFzeSB1c2Ugb2YgYSBzZXJ2 aWNlIG1vZGVsIGFuZCB0byBhdm9pZCB0aGUgbWlzY29uZmlndXJhdGlvbiBhbmQgaW5jb25zaXN0 ZW5jeSwgd2UgaGF2ZSB0byBleGNsdWRlIGR1cGxpY2F0ZSBjb25maWd1cmF0aW9uIGZvciB0aGUg c2FtZSBpbmZvcm1hdGlvbiwgZGF0YSBub2RlIGluc3RhbmNlLCBhcyBtdWNoIGFzIHBvc3NpYmxl LiA+VGhlbiwgSSBwcm9wb3NlZCB0byByZW1vdmUgcmVwZXRpdGl2ZSBkZWZpbml0aW9ucyBvZiBh IHZwbiB3aGljaCBjYW4gYmUgaW1wbGljaXRseSB1bmlxdWVseSBpZGVudGlmaWVkIGluIGEgc2Ft ZSB0cmFuc2FjdGlvbi4gQnV0LCB0aGF0IGV2ZW50dWFsbHkgY2FtZSBub3QgdG8gbWFrZSBzZW5z ZSBmb3IgcmVzdGNvbmYuDQo+SW4gdGhhdCBzZW5zZSwgSSBiYXNpY2FsbHkgcHJlZmVyIHRoZSBj dXJyZW50IG1vZGVsLg0KPltBaWp1biBXYW5nXTogZm9yIHNpdGVzIHRoYXQgYmVsb25nIHRvIHNl dmVyYWwgdnBucywgYmVjYXVzZSB3ZSBkZWZpbmUgInZwbi1zdmMiIGFzIGxpc3QsIHRoZW4gaXQg Y2FuIGluY2x1ZGUgZGlmZmVyZW50IGl0ZW1zLCBlYWNoIHZwbi1zdmMgaXRlbSBjYW4gZGVmaW5l IGl0cyBvd24gc2l0ZXMgY292ZXJhZ2UgaW5mb3JtYXRpb24uID5UaGVyZSBpcyBhbHNvIG5vIGR1 cGxpY2F0ZSBjb25maWd1cmF0aW9uIGZvciB0aGlzIHNvbHV0aW9uLiBXaGF0J3MgdGhlIHByb2Js ZW0gdGhlbiBmb3IgdGhpcyBhcnJhbmdlbWVudD8NCg0KSWYgYSBwaHlzaWNhbCBjdXN0b21lciBz aXRlIGNvbm5lY3RzIHRvIHR3byBkaWZmZXJlbnQgdnBucyBpbiB0aGlzIGNhc2UsIHRoZSBjdXN0 b21lciBtdXN0IGlucHV0IG9yIHVwZGF0ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIChwaHlz aWNhbCkgc2l0ZSBkdXBsaWNhdGVseSBwZXIgdnBuLXN2Yy4gVGhpcyBtYXkgY2F1c2UgbWlzY29u ZmlndXJhdGlvbiBhbmQgYm90aGVyIG91ciBjdXN0b21lcnMuDQpBbm90aGVyIGNvbmNlcm4gaXMg dGhlIGluY29uc2lzdGVuY3kgd2l0aCBhY2NvdW50aW5nL2NoYXJnaW5nIG1vZGVsLCB3aGVuIGFu IG9wZXJhdG9yIGNoYXJnZXMgdGhlIGZlZSBmb3IgcGh5c2ljYWwgYWNjZXNzLCBpdCBiZWNvbWVz IGluY29uc2lzdGVudCB3aXRoIHRoZSBjaGFyZ2luZyBtb2RlbC4gV2hlbiB3ZSBkb2VzIGEgdHJh ZmZpYyBhY2NvdW50aW5nIG5vdCBvbmx5IGZvciBsb2dpY2FsIGFjY2VzcyBwZXIgdnBuLCBidXQg YWxzbyBmb3IgcGh5c2ljYWwgYWNjZXNzLCB3ZSBtdXN0IGFsd2F5cyB0YWtlIGNhcmUgb2YgdGhl IGV4aXN0ZW5jZSBvZiBkaWZmZXJlbnQgdnBuLXN2YyB3aXRoIHRoZSBzYW1lIHBoeXNpY2FsIGFj Y2VzcyBpbiBvcmRlciB0byB0cmlnZ2VyIGEgcG9sbGluZyB0cmFmZmljIGNvdW50ZXIgb2YgdGhl IGludGVyZmFjZSBvbiBQRS4NCg0KSSB1bmRlcnN0YW5kIGl0IGRlcGVuZHMgb24gZWFjaCBvcGVy YXRvcidzIHNlcnZpY2UgZGVmaW5pdGlvbiwgdnBuIHNwZWNpZmljIG9yIHNpdGUgc3BlY2lmaWMs IGFzIFN0ZXBoYW5lIHdyb3RlLg0KDQpUbyBhY2NvbW1vZGF0ZSB0aGVzZSBkaWZmZXJlbnQgcmVx dWlyZW1lbnRzLCBJIHRoaW5rIHRoZSBsb29zZSBjb3VwbGVkIG1vZGVsIGJldHdlZW4gdGhlIGNv bXBvbmVudHMsIHZwbiBhbmQgc2l0ZSwgc2VlbXMgYmV0dGVyLg0KDQpUaGFua3MsDQpLZW5pY2hp DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KU2VudDogV2VkbmVzZGF5 LCBGZWJydWFyeSAyNCwgMjAxNiAxMDowNiBBTQ0KVG86ICdPZ2FraSwgS2VuaWNoaSc7IHN0ZXBo YW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0wz c21dIElzc3VlICMxMCBSRTogTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2Rh eSBMM1NNIGludGVyaW0gc2Vzc2lvbg0KDQpIaSwgT2dha2k6DQoNClBsZWFzZSBzZWUgdGhlIHJl cGx5IGlubGluZS4NCg0KDQpCZXN0IFJlZ2FyZHMuDQoNCkFpanVuIFdhbmcNCg0KQ2hpbmEgVGVs ZWNvbSBDb3Jwb3JhdGlvbiBMaW1pdGVkIEJlaWppbmcgUmVzZWFyY2ggSW5zdGl0dXRlIE5ldHdv cmsgUmVzZWFyY2ggYW5kIE9wZXJhdGlvbiBTdXBwb3J0IERlcGFydG1lbnQNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE9nYWtpLCBLZW5pY2hpIFttYWlsdG86a2Utb29nYWtp QGtkZGkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA4OjExIEFNDQpU bzogJ0FpanVuIFdhbmcnOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBpZXRm Lm9yZw0KU3ViamVjdDogUkU6IFtMM3NtXSBJc3N1ZSAjMTAgUkU6IEwzU00gaW50ZXJpbSBtZWV0 aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KSGkgQWlqdW4s DQoNClNlZSBjb21tZW50cyBpbmxpbmUsIHBsZWFzZS4NCg0KVGhhbmtzLA0KS2VuaWNoaQ0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFpanVuIFdhbmcNClNlbnQ6IFRodXJzZGF5LCBGZWJy dWFyeSAxOCwgMjAxNiAxOjEyIFBNDQpUbzogJ09nYWtpLCBLZW5pY2hpJzsgc3RlcGhhbmUubGl0 a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTDNzbV0gSXNz dWUgIzEwIFJFOiBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9uIFRodXJzZGF5IEwzU00g aW50ZXJpbSBzZXNzaW9uDQoNCkhpLCBTdGVwaGFuZSBhbmQgT2dha2k6DQoNCiANCg0KSSBzdWdn ZXN0ZWQgd2UgcHV0IHRoZSAiZXh0cmFuZXQtdnBuLXBvbGljeSIgdW5kZXIgdGhlIGxpc3QgInZw bi1zdmMiIGRpcmVjdGx5LCBub3QgaW4gdGhlIGNvbnRhaW5lciAidnBuLXBvbGljeSIgdGhhdCBp cyBub3cgdW5kZXIgdGhlIGxpc3QgInNpdGVzIiBpbiBjdXJyZW50IG1vZGVsLiANCg0KW0tPXUxp a2UgdGhpcz8NCg0KICAgIGNvbnRhaW5lciBsM3Zwbi1zdmMgew0KICAgICAgICBsaXN0IHZwbi1z dmMgew0KICAgICAgICAgICAga2V5IHZwbi1pZDsNCg0KICAgICAgICAgICAgbGVhZiB2cG4taWQg ew0KICAgICAgICAgICAgICAgIOKApg0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgLi4uDQog ICAgICAgICAgICBsaXN0IGV4dHJhbmV0LXZwbi1wb2xpY3kgew0KICAgICAgICAgICAgICAgIGtl eSB2cG4taWQ7DQogICAgICAgICAgICAgICAgbGVhZiB2cG4taWQgew0KICAgICAgICAgICAgICAg ICAgICB0eXBlIHN2Yy1pZDsNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICB9DQogICAg ICAgICAgICAuLi4NCiAgICAgICAgfQ0KICAgICAgICAuLi4NCiAgICB9DQpbQWlqdW4gV2FuZ106 IFllcy4NCg0KVGhpcyBjYW4gc29sdmUgdGhlIGluaXRpYWwgc2NlbmFyaW8gdGhhdCBwcm9wb3Nl ZCBieSBLZW5pY2hpIGF0IHRoZSBiZWdpbm5pbmcgb2Ygb3VyIGRpc2N1c3Npb24uIFdoZW4gdGhl IG9yY2hlc3RyYXRvciByZWNlaXZlcyB0aGUgaW5mb3JtYXRpb24gZGVmaW5lZCBpbiAiZXh0cmFu ZXQtdnBuLXBvbGljeSIsIGl0IGNhbiBhbGxvY2F0ZSBuZXcgcm91dGUtdGFyZ2V0IGZvciB0aGUg aW52b2x2ZWQgVlBOcyBhbmQgc2V0IHRoZW0gaW4gdGhlIGNvbmZpZ3VyYXRpb24gc3RhbnphIG9m IGVhY2ggcm91dGVyLg0KDQogDQoNCkZvciB0aGUgcmVsYXRpb25zaGlwIG9mIGxpc3QgInZwbi1z dmMiIGFuZCBsaXN0ICJzaXRlcyIsIEkgc3RpbGwgc3VnZ2VzdCB3ZSBwdXQgdGhlIGxpc3QgInNp dGUiIHVuZGVyIHRoZSAidnBuLXN2YyIsIHRoZSByZWFzb24gZm9yIGRvaW5nIHRoaXMgaXMgYXMg YmVsb3c6DQoNCjEuIHRoZSBzZXJ2aWNlIG1vZGVsIG11c3QgYmUgc2VydmljZSBvcmllbnRlZC4g SWYgb25lIHNpdGUgYmVsb25ncyB0byBzZXZlcmFsIHZwbnMsIHdlIHNob3VsZCBhY2hpZXZlIHRo ZSBnb2FsIGJ5IGRlZmluaW5nIHNldmVyYWwgc2VydmljZSBpbnN0YW5jZXMuDQoNCltLT10gSSBj YW4ndCBhZ3JlZSB0aGlzLiBUaGUgY2FzZSB0aGF0IGEgc2l0ZSBiZWxvbmdzIHRvIG11bHRpcGxl IHZwbnMgaXMgYWxzbyBhIHZlcnkgY29tbW9uIHNlcnZpY2UgdXNlIGNhc2UsIHRoZW4gdGhlIHNl cnZpY2UgbW9kZWwgbXVzdCBkZXNpZ24gdGhpcyBhcHByb3ByaWF0ZWx5Lg0KRm9yIGVhc3kgdXNl IG9mIGEgc2VydmljZSBtb2RlbCBhbmQgdG8gYXZvaWQgdGhlIG1pc2NvbmZpZ3VyYXRpb24gYW5k IGluY29uc2lzdGVuY3ksIHdlIGhhdmUgdG8gZXhjbHVkZSBkdXBsaWNhdGUgY29uZmlndXJhdGlv biBmb3IgdGhlIHNhbWUgaW5mb3JtYXRpb24sIGRhdGEgbm9kZSBpbnN0YW5jZSwgYXMgbXVjaCBh cyBwb3NzaWJsZS4gVGhlbiwgSSBwcm9wb3NlZCB0byByZW1vdmUgcmVwZXRpdGl2ZSBkZWZpbml0 aW9ucyBvZiBhIHZwbiB3aGljaCBjYW4gYmUgaW1wbGljaXRseSB1bmlxdWVseSBpZGVudGlmaWVk IGluIGEgc2FtZSB0cmFuc2FjdGlvbi4gQnV0LCB0aGF0IGV2ZW50dWFsbHkgY2FtZSBub3QgdG8g bWFrZSBzZW5zZSBmb3IgcmVzdGNvbmYuDQpJbiB0aGF0IHNlbnNlLCBJIGJhc2ljYWxseSBwcmVm ZXIgdGhlIGN1cnJlbnQgbW9kZWwuDQpbQWlqdW4gV2FuZ106IGZvciBzaXRlcyB0aGF0IGJlbG9u ZyB0byBzZXZlcmFsIHZwbnMsIGJlY2F1c2Ugd2UgZGVmaW5lICJ2cG4tc3ZjIiBhcyBsaXN0LCB0 aGVuIGl0IGNhbiBpbmNsdWRlIGRpZmZlcmVudCBpdGVtcywgZWFjaCB2cG4tc3ZjIGl0ZW0gY2Fu IGRlZmluZSBpdHMgb3duIHNpdGVzIGNvdmVyYWdlIGluZm9ybWF0aW9uLiBUaGVyZSBpcyBhbHNv IG5vIGR1cGxpY2F0ZSBjb25maWd1cmF0aW9uIGZvciB0aGlzIHNvbHV0aW9uLiBXaGF0J3MgdGhl IHByb2JsZW0gdGhlbiBmb3IgdGhpcyBhcnJhbmdlbWVudD8gDQoNCg0KMi4gVGhlIGF0dHJpYnV0 ZXMgb2YgInNpdGVzIiwgc3VjaCBhcyAibWF4aW11bS1yb3V0ZXMiLCAic2VjdXJpdHkiLCAic2Vy dmljZSIsICJyb3V0aW5nLXByb3RvY29scyIsInNpdGUtbmV0d29rLWFjY2Vzc2VzIiBldGMuIGFy ZSBhbGwgc2VydmljZS9zaXRlIHJvbGUgcmVsYXRlZCwgdGhhdCBpcyB0byBzYXksIGlmIHRoZSBz aXRlIHJvbGUgY2hhbmdlZCwgYWxsIG9mIHRoZXNlIGF0dHJpYnV0ZWQgbWF5IGJlIGNoYW5nZWQg YWNjb3JkaW5nbHkuDQoNCg0KW0tPXSBJIGJhc2ljYWxseSBhZ3JlZS4gVGhlIGF0dHJpYnV0ZXMg dGllZCB0byBhIHdob2xlIHZwbiBhbmQgZ2xvYmFsbHkgYXBwbGllZCB0byBhbGwgdGhlIHNpdGVz IHVuZGVyIHRoZSB2cG4gc2hvdWxkIGJlIGRlZmluZWQgd2l0aCB0aGUgdnBuIGRlZmluaXRpb24u DQoNCg0KMy5Gb3IgY29udGFpbmVyICJ2cG4gcG9saWN5IiB0aGF0IHVuZGVyIGxpc3QgInNpdGVz IiBpbiBjdXJyZW50IG1vZGVsLCB0aGVyZSBhcmUgdHdvIGluZm9ybWF0aW9uIGRlZmluZWQsIG9u ZSBpcyAiZmlsdGVyIiBmb3IgcHJlZml4IGZpbHRlcmluZywgYW5vdGhlciBpcyAic2l0ZS1yb2xl Ii4gSSBzdWdnZXN0IHdlIHNwbGl0IGl0LCBwdXQgdGhlIGxlYWYgInNpdGUtcm9sZSIgdW5kZXIg bGVhZiAic2l0ZS1pZCIgZGlyZWN0bHksIGFuZCBjaGFuZ2UgdGhlIG5hbWUgb2YgInZwbi1wb2xp Y3kiIHRvICJzaXRlLXByZWZpeC1wb2xpY3kiLiANCg0KIA0KDQpUaGUgZmluYWwgc3VnZ2VzdCBz dHJ1Y3R1cmUgb2YgdGhlIEwzVlBOIHlhbmcgbW9kZWwgd2lsbCBiZSBsb29rIGxpa2UgdGhlIGJl bGxvdywgSSB1bmRlcmxpbmUgdGhlIGNoYW5nZWQgcG9zaXRpb25zIGZyb20gdGhlIGN1cnJlbnQg bDN2cG4gWWFuZyBNb2RlbA0KDQogDQoNCkNvbnRhaW5lciBMM3Zwbi1zdmMNCg0KICAgTGlzdCB2 cG4tc3ZjDQoNCiAgIExlYWYgdnBuLWlkDQoNCiAgIExlYWYgY3VzdG9tZXItbmFtZQ0KDQogICBM ZWFmIHRvcG9sb2d5DQoNCiAgIExpc3QgZXh0cmFuZXQtdnBuLXBvbGljeQ0KDQogICBDb250YWlu ZXIgY2xvdWQtYWNjZXNzDQoNCiAgIExpc3QgbXVsdGljYXN0DQoNCiAgIExlYWYgbXBscw0KDQog ICBMaXN0IHRyYW5zcG9ydC1jb250cmFpbnRzDQoNCiAgIA0KDQogICBMaXN0IHNpdGVzDQoNCiAg ICAgTGVhZiBzaXRlLWlkDQoNCiAgICAgTGVhZiBzaXRlLXJvbGUNCg0KICAgICBsZWFmIGFwcGx5 LXRlbXBsYXRlDQoNCiAgICAgLi4uIC4uLg0KDQogICAgIC4uLiAuLi4NCg0KICAgICBDb250YWlu ZXIgbWFuYWdlbnQNCg0KICAgICBDb250YWluZXIgc2l0ZS1wcmVmaXgtcG9saWN5DQoNCiAgICAg Q29udGFpbmVyIG1heGltdW0tcm91dGVzDQoNCiAgICAgQ29udGFpbmVyIHNlY3VyaXR5DQoNCiAg ICAgLi4uIC4uLg0KDQogICAgIC4uLiAuLi4NCg0KICAgICBTaXRlLW5ldHdvcmstYWNjZXNzIA0K DQogDQoNCiANCg0KV2hldGhlciBpcyBpdCBtb3JlIHJlYXNvbmFibGU/IA0KDQogDQoNCiANCg0K QmVzdCBSZWdhcmRzLg0KDQogDQoNCkFpanVuIFdhbmcNCg0KIA0KDQpDaGluYSBUZWxlY29tIENv cnBvcmF0aW9uIExpbWl0ZWQgQmVpamluZyBSZXNlYXJjaCBJbnN0aXR1dGUgDQoNCk5ldHdvcmsg UmVzZWFyY2ggYW5kIE9wZXJhdGlvbiBTdXBwb3J0IERlcGFydG1lbnQNCg0KIA0KDQogDQoNCiAN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEwzc20gW21haWx0bzpsM3NtLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBPZ2FraSwgS2VuaWNoaQ0KU2VudDogVGh1cnNk YXksIEZlYnJ1YXJ5IDE4LCAyMDE2IDk6MDggQU0NClRvOiBsM3NtQGlldGYub3JnDQpTdWJqZWN0 OiBbTDNzbV0gSXNzdWUgIzEwIFJFOiBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9uIFRo dXJzZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCiANCg0KSGkgU3RlcGhhbmUgYW5kIEFsbCwN Cg0KIA0KDQpBcyBmb3IgaXNzdWUgIzEwIGl0c2VsZiwgdGhlIGZvbGxvd2luZyBzb2x1dGlvbiBj YW4gYmUgYWNjZXB0YWJsZSBmb3IgdXMuDQoNCiANCg0KPk9uZSBwcm9wb3NhbCBjb3VsZCBiZSB0 byBub3QgY2FsbCB0aGlzIFZQTiBwb2xpY3ksIGJ1dCBjcmVhdGluZyBhDQoNCj5jb250YWluZXIg ImV4dHJhbmV0LXZwbi1wb2xpY3kiIGF0IHZwbiBsZXZlbCB3aGljaCB3aWxsIG1hbmRhdGUgYW4g ZXh0cmFuZXQgVlBOIGFyY2hpdGVjdHVyZSBmcm9tIGEgY29uZmlndXJhdGlvbiBwb2ludCBvZiB2 aWV3LCBkZWR1Y2luZyBhdXRvbWF0aWNhbGx5IHRoZSBhcHByb3ByaWF0ZSBSVCBydWxlcyB0byBh ZGQgKGxpa2UgY3JlYXRpbmcgYSBuZXcgcGFpciBvZiBSVHMpLg0KDQogDQoNCldoYXQgbW9kZWwg aXMgaW4geW91ciBtaW5kPyBJIGNhbid0IHNlZSB3aGF0ICIiZXh0cmFuZXQtdnBuLXBvbGljeSIg YXQgdnBuIiBtZWFucy4NCg0KTGlrZSB0aGlzPw0KDQogDQoNCjx2cG4tc3ZjPg0KDQogICAuLi4N Cg0KICAgPHZwbi1wb2xpY3k+DQoNCiAgICAgICA8ZW50cmllcz4NCg0KICAgICAgICAgICA8aWQ+ MTwvaWQ+DQoNCiAgICAgICAgICAgPHZwbj4NCg0KICAgICAgICAgICAgICAgPHZwbi1pZD5WUE4x PC92cG4taWQ+DQoNCiAgICAgICAgICAgPC92cG4+DQoNCiAgICAgICAgICAgPGV4dHJhbmV0LXZw bi1wb2xpY3k+DQoNCiAgICAgICAgICAgICAgIDxleHRyYW5ldC12cG4+DQoNCiAgICAgICAgICAg ICAgICAgICA8dnBuLWlkPlZQTjI8L3Zwbi1pZD4NCg0KICAgICAgICAgICAgICAgPC9leHRyYW5l dC12cG4+DQoNCiAgICAgICAgICAgPC9leHRyYW5ldC12cG4tcG9saWN5Pg0KDQogICAgICAgPC9l bnRyaWVzPg0KDQogICA8L3Zwbi1wb2xpY3k+DQoNCiAgIC4uLg0KDQo8L3Zwbi1zdmM+DQoNCiAN Cg0KVGhhbmtzLA0KDQpLZW5pY2hpDQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cg0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOmwzc20t Ym91bmNlc0BpZXRmLm9yZz4gXSBPbiBCZWhhbGYgT2Ygc3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb20gPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gDQoNClNlbnQ6IE1v bmRheSwgRGVjZW1iZXIgMDcsIDIwMTUgMTE6NDUgUE0NCg0KVG86IE9nYWtpLCBLZW5pY2hpOyAn QWlqdW4gV2FuZyc7ICdRaW4gV3UnOyBsM3NtQGlldGYub3JnIDxtYWlsdG86bDNzbUBpZXRmLm9y Zz4gDQoNCkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrIDxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51 az4gDQoNClN1YmplY3Q6IFJlOiBbTDNzbV0gTDNTTSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBv biBUaHVyc2RheSBMM1NNIGludGVyaW0gc2Vzc2lvbg0KDQogDQoNCkhpIEtlbmljaGksDQoNCiAN Cg0KUmVnYXJkaW5nIHlvdXIgcHJvcG9zYWwgb2YgaGF2aW5nIGEgc2ltcGxlIFZQTiBwb2xpY3kg aW4gdGhlIHZwbi1zdmMgY29udGFpbmVyLCBJIGRvIHNlZSBhbiBpc3N1ZS4gT25lIG9mIHRoZSBr ZXkgcG9pbnQgb2YgdGhlIFZQTiBwb2xpY3kgaXMgdG8gZXhwcmVzcyB0aGUgcm9sZSBvZiB0aGUg c2l0ZSBpbiB0aGUgdGFyZ2V0IFZQTiB0b3BvbG9neS4NCg0KSWYgd2UgZG8gYSB2cG4gcG9saWN5 IGF0IFZQTiBsZXZlbCwgd2UgY2Fubm90IGFueW1vcmUgZGVzY3JpYmUgc2l0ZSByb2xlcyBpbiB0 aGUgdGFyZ2V0IFZQTiB3aGljaCBjYXVzZXMgYW4gaXNzdWUuDQoNCkluIGFuIGlkZWFsIHdvcmxk IHdoZXJlIGFsbCBWUE5zIGFyZSBhbnkgdG8gYW55LCB0aGUgc2l0ZSByb2xlIGlzIGFsd2F5cyB0 aGUgc2FtZSBhbmQgdGhlcmUgaXMgbm8gaXNzdWUsIGJ1dCBsZXQncyB0aGluayBhYm91dCBzb21l b25lIHRyeWluZyB0byB1c2UgdGhlIHZwbi1wb2xpY3kgKGF0IHZwbiBsZXZlbCkgdG8gY29ubmVj dCB0byBhIEh1YiAmIFNwb2tlIFZQTiwgaG93IGRvIHlvdSBkZWR1Y2UgdGhlIHJvbGVzIG9mIHRo ZSBzaXRlcyA/DQoNCiANCg0KT25lIHByb3Bvc2FsIGNvdWxkIGJlIHRvIG5vdCBjYWxsIHRoaXMg VlBOIHBvbGljeSwgYnV0IGNyZWF0aW5nIGEgY29udGFpbmVyICJleHRyYW5ldC12cG4tcG9saWN5 IiBhdCB2cG4gbGV2ZWwgd2hpY2ggd2lsbCBtYW5kYXRlIGFuIGV4dHJhbmV0IFZQTiBhcmNoaXRl Y3R1cmUgZnJvbSBhIGNvbmZpZ3VyYXRpb24gcG9pbnQgb2YgdmlldywgZGVkdWNpbmcgYXV0b21h dGljYWxseSB0aGUgYXBwcm9wcmlhdGUgUlQgcnVsZXMgdG8gYWRkIChsaWtlIGNyZWF0aW5nIGEg bmV3IHBhaXIgb2YgUlRzKS4gVGhpcyBtZWFucyB0aGF0IHRoZSB1c2FnZSBpcyByZWFsbHkgbGlt aXRlZCB0byAic2ltcGxlIiBleHRyYW5ldC12cG5zIGFuZCBpdCBkb2VzIG5vdCByZXBsYWNlIG5v ciBjb21wZXRlIHdpdGggdGhlIFZQTiBwb2xpY3kgYXQgc2l0ZSBsZXZlbC4NCg0KIA0KDQpDb3Vs ZCBpdCBiZSBhIGdvb2QgY29tcHJvbWlzZSA/DQoNCiANCg0KU3RlcGhhbmUNCg0KIA0KDQogDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IE9nYWtpLCBLZW5pY2hpIFttYWls dG86a2Utb29nYWtpQGtkZGkuY29tIDxtYWlsdG86a2Utb29nYWtpQGtkZGkuY29tPiBdDQoNClNl bnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAwNSwgMjAxNSAwNjoyMw0KDQpUbzogTElUS09XU0tJIFN0 ZXBoYW5lIFNDRS9PSU5JUzsgJ0FpanVuIFdhbmcnOyAnUWluIFd1JzsgbDNzbUBpZXRmLm9yZyA8 bWFpbHRvOmwzc21AaWV0Zi5vcmc+IA0KDQpDYzogYWRyaWFuQG9sZGRvZy5jby51ayA8bWFpbHRv OmFkcmlhbkBvbGRkb2cuY28udWs+IA0KDQpTdWJqZWN0OiBSRTogW0wzc21dIEwzU00gaW50ZXJp bSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KIA0K DQpEZWFyIFN0ZXBoYW5lIGFuZCBBbGwsDQoNCiANCg0KSSBkb24ndCBzYXkgdGhhdCBzaXRlcyAq bXVzdCogbW92ZSB1bmRlciB2cG4tc3ZjIGJlY2F1c2UgSSB1bmRlcnN0YW5kIHN0ZXBoYW5lJ3Mg dXNlIGNhc2UuDQoNCkJ1dCB3ZSBhbHJlYWR5IGhhdmUgdnBuLXN2YyBhbmQgc29tZSBwYXJhbWV0 ZXJzIHVuZGVyIHRoaXMgYXJlIGdsb2JhbGx5IGFwcGxpZWQgdG8gYWxsIHRoZSBzaXRlcyBldmVu IGluIHRoZSBjdXJyZW50IG1vZGVsLg0KDQogDQoNCkl0IGRlcGVuZHMgb24gb3BlcmF0b3IncyB1 c2UgY2FzZSB3aGljaCBpcyBzaXRlLW9yaWVudGVkIG9yIHZwbi1vcmllbnRlZCBzZXJ2aWNlLg0K DQpPdXIgc2VydmljZSBpcyB2cG4tb3JpZW50ZWQsIHNpdGUgaGFzIHRoZSBuYXRpdmUgVlBOLiBU aGVuLCBJIHdvdWxkIGp1c3QgbGlrZSB5b3UgdG8gYWxsb3cgb3RoZXIgZ2xvYmFsIG9wdGlvbnMg dG8gdnBuLXN2Yy4NCg0KIA0KDQpUaGFua3MsDQoNCktlbmljaGkNCg0KIA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSA8 bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiAgW21haWx0bzpzdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbSA8bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29t PiBdDQoNClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDQsIDIwMTUgODoxNyBQTQ0KDQpUbzogQWlq dW4gV2FuZzsgJ09nYWtpLCBLZW5pY2hpJzsgJ1FpbiBXdSc7IGwzc21AaWV0Zi5vcmcgPG1haWx0 bzpsM3NtQGlldGYub3JnPiANCg0KQ2M6IGFkcmlhbkBvbGRkb2cuY28udWsgPG1haWx0bzphZHJp YW5Ab2xkZG9nLmNvLnVrPiANCg0KU3ViamVjdDogUkU6IFtMM3NtXSBMM1NNIGludGVyaW0gbWVl dGluZyBtaW51dGVzIG9uIFRodXJzZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCiANCg0KSGks DQoNCiANCg0KSSdtIGFnYWluc3QgdGhpcyBwcm9wb3NhbCwgYXMgSSBkbyBub3Qgd2FudCB0byBj cmVhdGUgYW55IGRlcGVuZGVuY3kgYmV0d2VlbiBhIHBhcnRpY3VsYXIgVlBOIGFuZCBhIGxpc3Qg b2Ygc2l0ZXMuDQoNCkEgc2l0ZSBjYW4gYmVsb25nIHRvIG11bHRpcGxlIFZQTnMgd2l0aCBhbnkg a2luZCBvZiB0b3BvbG9neSwgaWYgd2UgYXR0YWNoIHRoZSBzaXRlIHRvIGEgc2luZ2xlIFZQTiwg d2UgY29tZSBiYWNrIHRvIHRoZSBub3Rpb24gb2YgIm5hdGl2ZSBWUE4iIHdlIGhhZCBhdCB0aGUg YmVnaW5uaW5nIG9mIHRoZSBtb2RlbCB3aGljaCB3YXMgaGFyZCB0byB1bmRlcnN0YW5kIGFuZCBz byB3YXMgcmVtb3ZlZC4NCg0KIA0KDQogDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoN CkZyb206IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpsM3NtLWJv dW5jZXNAaWV0Zi5vcmc+IF0gT24gQmVoYWxmIE9mIEFpanVuIFdhbmcNCg0KU2VudDogRnJpZGF5 LCBEZWNlbWJlciAwNCwgMjAxNSAwMjo0NA0KDQpUbzogJ09nYWtpLCBLZW5pY2hpJzsgJ1FpbiBX dSc7IGwzc21AaWV0Zi5vcmcgPG1haWx0bzpsM3NtQGlldGYub3JnPiANCg0KQ2M6IGFkcmlhbkBv bGRkb2cuY28udWsgPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPiANCg0KU3ViamVjdDogUmU6 IFtMM3NtXSBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9uIFRodXJzZGF5IEwzU00gaW50 ZXJpbSBzZXNzaW9uDQoNCiANCg0KRGVhciBhbGw6DQoNCiANCg0KQ2FuIHdlIHB1dCB0aGUgbGlz dCAic2l0ZXMiIHdpdGhpbiB0aGUgbGlzdCAidnBuLXN2YyIsIGFuZCBkZWZpbmUgdGhlIGdlbmVy YWwgdnBuIHBvbGljeSBmb3IgYWxsIHNpdGVzIHRoYXQgd2l0aGluIHRoZSBjb3JyZXNwb25kaW5n IHZwbiBzZXJ2aWNlIGluc3RhbmNlPw0KDQpJZiBkb2luZyBzbywgc29tZSBlbnRyaWVzIHdpdGhp biB0aGUgY3VycmVudCBsaXN0ICJzaXRlcyIgY2FuIGFsc28gYmUgZHJhZ2dlZCBvdXQgZm9yIGdl bmVyYWwgdXN1YWwgcHVycG9zZXMsIGZvciBleGFtcGxlLCAibWF4aW11bS1yb3V0ZXMiLCAic2Vj dXJpdHkiIGV0Yy4gVGhlc2UgcGFyYW1ldGVycyBhcmUgb2Z0ZW4gYWxsIHNhbWUgZm9yIGV2ZXJ5 IHNpdGUgd2l0aGluIG9uZSBWUE4gc2VydmljZSBpbnN0YW5jZS4gDQoNCiANCg0KSWYgc29tZSBz aXRlcyBoYXZlIHNwZWNpYWwgcmVxdWlyZW1lbnRzLCB3ZSBjYW4gYWNoaWV2ZSB0aGlzIGJ5IHVz aW5nIHNvbWUgc3BlY2lhbCAic2l0ZS12cG4tcG9saWN5IiB3aXRoaW4gdGhlIGNvcnJlc3BvbmRp bmcgc2l0ZSBkZWZpbml0aW9uLg0KDQpJcyB0aGlzIG1vcmUgYWNjZXB0YWJsZSBmb3IgY3VzdG9t ZXJzPw0KDQogDQoNCiANCg0KQmVzdCBSZWdhcmRzLg0KDQogDQoNCkFpanVuIFdhbmcNCg0KIA0K DQpDaGluYSBUZWxlY29tIENvcnBvcmF0aW9uIExpbWl0ZWQgQmVpamluZyBSZXNlYXJjaCBJbnN0 aXR1dGUgSW50ZWxsaWdlbnQgTmV0d29yayBQcm9kdWN0IExpbmUNCg0KIA0KDQogDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNA aWV0Zi5vcmcgPG1haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmc+IF0gT24gQmVoYWxmIE9mIE9n YWtpLCBLZW5pY2hpDQoNClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDQsIDIwMTUgOTowMiBBTQ0K DQpUbzogJ1FpbiBXdSc7IGwzc21AaWV0Zi5vcmcgPG1haWx0bzpsM3NtQGlldGYub3JnPiANCg0K Q2M6IGFkcmlhbkBvbGRkb2cuY28udWsgPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPiANCg0K U3ViamVjdDogUmU6IFtMM3NtXSBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9uIFRodXJz ZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCiANCg0KRGVhciBBbGwsDQoNCiANCg0KSXQgd2Fz IGdvb2QgaGF2aW5nIGRpc2N1c3Npb24uDQoNCiANCg0KQXMgZm9yIGlzc3VlIzEwLCB0aGUgb2Jq ZWN0aXZlIGFuZCBwcm9ibGVtIHdlIGRpc2N1c3NlZCBpbiB0aGUgbWVldGluZyBhcyBmb2xsb3dz Lg0KDQogDQoNClRoZSBvYmplY3RpdmUgaXMgdG8gcHJvdmlkZSBwZXItVlBOIGV4dHJhbmV0IHNl cnZpY2Ugd2hpY2ggY29ubmVjdHMgdHdvIGRpZmZlcmVudCBWUE5zIChlLmcuIFZQTjEgYW5kIFZQ TjIpLiBJdCBtZWFucyB0aGF0IGFueSBzaXRlcyBpbiBWUE4xIGNhbiBhY2Nlc3MgdG8gYW55IHNp dGVzIGluIFZQTjIuDQoNClRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGN1cnJlbnQgbW9kZWwgbXVz dCB1cGRhdGUgdnBuLXBvbGljeSB1bmRlciBhbGwgdGhlIHNpdGVzIGJlbG9uZyB0byB0aGVzZSB0 d28gVlBOcyBpbiBvcmRlciB0byBvZmZlciB0aGlzIHNlcnZpY2UuIEVzcGVjaWFsbHkgd2hlbiB0 aGlzIG1vZGVsIGlzIHVzZWQgYXMgYSBjdXN0b21lciBzZWxmLWNvbnRyb2wgQVBJLCBpdCdzIG5v dCBnb29kIGlkZWEgdG8gcmVxdWlyZSBjdXN0b21lcnMgdG8gdXBkYXRlIHRoZSBpbmZvcm1hdGlv biBvZiBhbGwgdGhlIHNpdGVzLiAoSXQncyBub3QgYWJzdHJhY3RlZCB3YXksIGEgc2VydmljZSBt b2RlbCBzaG91bGQgcHJvdmlkZSB3aGF0IHRoZSBjb25zdW1lciB3YW50cywgbm90IGhvdy4pIElm IGEgc2VydmljZSBvciBjdXN0b21lciByZXF1aXJlcyB0byBjb250cm9sIHBlci1zaXRlIHZwbi1w b2xpY3ksIHRoYXQgb2YgY3VycmVudCBtb2RlbCBzaG91bGQgYmUgdXNlZCB3aXRob3V0IHNldHRp bmcgcGVyLVZQTiB2cG4tcG9saXR5LiBJdCBkZXBlbmRzIG9uIGVhY2ggb3BlcmF0b3IncyBzZXJ2 aWNlLg0KDQpTdGVwaGFuZSBwcm9wb3NlZCB0byB1c2UgYXBwbHktdGVtcGxhdGUsIGJ1dCBpdCBz dGlsbCBjYW5ub3Qgc29sdmUgdGhlIHByb2JsZW0uIFdoZW4gZWFjaCBWUE4gYWxyZWFkeSBoYXMg YSBsYXJnZSBudW1iZXIgb2Ygc2l0ZXMgYW5kIHdhbnQgdG8gY29ubmVjdCBlYWNoIG90aGVyIGZv ciB0aGUgZmlyc3QgdGltZSwgYm90aCBWUE5zIG11c3QgdXBkYXRlIHRoZXNlIHNpdGVzIHRvIGFw cGx5IGFwcGx5LXRlbXBsYXRlIG9uIHRoZSBjdXJyZW50IG1vZGVsLg0KDQogDQoNClRoYW5rcywN Cg0KS2VuaWNoaQ0KDQogDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IEwz c20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpsM3NtLWJvdW5jZXNAaWV0 Zi5vcmc+IF0gT24gQmVoYWxmIE9mIFFpbiBXdQ0KDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDA0 LCAyMDE1IDEyOjQyIEFNDQoNClRvOiBsM3NtQGlldGYub3JnIDxtYWlsdG86bDNzbUBpZXRmLm9y Zz4gDQoNCkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrIDxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51 az4gDQoNClN1YmplY3Q6IFtMM3NtXSBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9uIFRo dXJzZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCiANCg0KSGkgYWxsOg0KDQogDQoNCiANCg0K QmVsb3cgaXMgdGhlIGluaXRpYWwgdmVyc2lvbiBvZiBkcmFmdCBtaW51dGVzIGZvciBUaHVyc2Rh eSBMM1NNIFdHIGludGVyaW0gc2Vzc2lvbi4NCg0KIA0KDQpUaGFua3MgRGFuIHRvIGhlbHAgdGFr ZSBtaW51dGVzLg0KDQogDQoNCkZvbGtzLCBwbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUg YW55IGNvcnJlY3Rpb24uDQoNCiANCg0KIA0KDQotUWluDQoNCiANCg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KDQogDQoNCkwzU00gV29ya2luZyBHcm91cCBWaXJ0dWFsIEludGVyaW0gTWVldGlu ZyANCg0KIA0KDQpUaHVyc2RheSBEZWNlbWJlciA1dGgsIDIwMTUuIDhhbSBFYXN0IENvYXN0IFRp bWUgKE5ldyBZb3JrKQ0KDQogDQoNCiANCg0KQkxVRSBTSEVFVA0KDQogDQoNCiANCg0KTmFtZSAg ICAgICAgICAgICAgICAgICAgfCBBZmZpbGlhdGlvbg0KDQogDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLQ0KDQogDQoNCkFkcmlhbiBGYXJyZWwgICAgICAg ICAgIHwgT2xkIERvZyBDb25zdWx0aW5nDQoNCiANCg0KUWluIFd1ICAgICAgICAgICAgICAgICAg fCBIdWF3ZWkgVGVjaG5vbG9naWVzDQoNCiANCg0KU3RlcGhhbmUgTGl0a293c2tpICAgICAgfCBP cmFuZ2UNCg0KIA0KDQpMdWlzIFRvbW90YWtpICAgICAgICAgICB8IFZlcml6b24NCg0KIA0KDQpE YW5pZWwgS2luZyAgICAgICAgICAgICB8IE9sZCBEb2cgQ29uc3VsdGluZw0KDQogDQoNClN1c2Fu IEhhcmVzICAgICAgICAgICAgIHwgSHVhd2VpIFRlY2hub2xvZ2llcw0KDQogDQoNClNjb3R0IE1h bnNmaWVsZCAgICAgICAgIHwgRXJpY3Nzb24NCg0KIA0KDQpHdSBSb25nICAgICAgICAgICAgICAg ICB8IENoaW5hIE1vYmlsZSANCg0KIA0KDQpLZW5pY2hpIE9nYWtpICAgICAgICAgICB8IEtEREkN Cg0KIA0KDQpBaWp1biBXYW5nICAgICAgICAgICAgICB8IENoaW5hIFRlbGVjb20NCg0KIA0KDQpW aWN0b3IgU2FudG9zICAgICAgICAgICB8IEVyaWNzc29uDQoNCiANCg0KSWduYXMgQmFnZG9uYXMg ICAgICAgICAgfCANCg0KIA0KDQogDQoNCiANCg0KIA0KDQogDQoNCiANCg0KIA0KDQogDQoNCiAN Cg0KTUlOVVRFUw0KDQogDQoNCiANCg0KKiBNZXRpbmcgbG9naWlzdGljcyBodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2wzc20vU0p1YjFhSFZRR09RVzZyV2h0aFgwZkI4QWM4 IDxodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2wzc20vU0p1YjFhSFZRR09R VzZyV2h0aFgwZkI4QWM4PiAgDQoNCiANCg0KKiBNZWV0aW5nIG1hdGVyaWFscyBodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTUvMTIvMDMvbDNzbS9wcm9jZWVkaW5n cy5odG1sIDxodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTUvMTIv MDMvbDNzbS9wcm9jZWVkaW5ncy5odG1sPiAgDQoNCiANCg0KKiBFdGhlcnBhZCBmb3IgbWludXRl cyAodGhpcyBwYWdlKSBodHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9wL2wzc20t aW50ZXJpbS0yMDE1LTEyLTAzIDxodHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9w L2wzc20taW50ZXJpbS0yMDE1LTEyLTAzPiANCg0KIA0KDQoqIEphYmJlciB1c2luZyBsM3NtQGph YmJlci5pZXRmLm9yZyA8bWFpbHRvOmwzc21AamFiYmVyLmlldGYub3JnPiANCg0KIA0KDQoqIEJs dWUgc2hlZXQgaHR0cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9sM3NtLWludGVy aW0tMjAxNS0xMi0wMy1ibHVlc2hlZXQgPGh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5 MDAwL3AvbDNzbS1pbnRlcmltLTIwMTUtMTItMDMtYmx1ZXNoZWV0PiANCg0KIA0KDQogDQoNCkFn ZW5kYWENCg0KIA0KDQotIEFkbWluaXN0cml2aWEgKE5vdGUgV2VsbCwgZXRjKS4gYQ0KDQogDQoN Ci0gSW50cm9kdWN0aW9uDQoNCiANCg0KLSBPcGVuIElzc3VlcyBmb3IgWUFORyBEYXRhIE1vZGVs IGZvciBMM1ZQTnNlcnZpY2UgZGVsaXZlcnkgKGRyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNl bW9kZWwpDQoNCiANCg0KbyBPcGVuIElzc3VlcyBkaXNjdXNzaW9uIGFuZCByZXNvbHV0aW9u4oCT IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2wzc20vdHJhYy9yZXBvcnQvMSA8aHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvbDNzbS90cmFjL3JlcG9ydC8xPiANCg0KIA0KDQogDQoN CkZvciBhIGZ1bGwgbGlzdCBvZiBpc3N1ZXMgYW5kIHJlc29sdXRpb24gcHJvcG9zYWxzIHBsZWFz ZSBzZWU6IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNS8xMi8w My9sM3NtL3NsaWRlcy9zbGlkZXMtaW50ZXJpbS0yMDE1LWwzc20tMS0yLnBkZiA8aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1LzEyLzAzL2wzc20vc2xpZGVzL3Ns aWRlcy1pbnRlcmltLTIwMTUtbDNzbS0xLTIucGRmPiANCg0KIA0KDQogDQoNCklzc3VlIzE6IFdo ZW4gY3VzdG9tZXItbmF0LWFkZHJlc3MgaXMgdXNlZA0KDQogDQoNClJlc29sdXRpb24gIzE6ICBM ZWFmIHVzZWQgd2hlbiBOQVQgaXMgcmVxdWlyZWQgdG8gYWNjZXNzIGNsb3VkIFZQTiBhbmQgY3Vz dG9tZXIgd2FudHMgdG8gdXNlIGl0cyBvd25JUCBhZGRyZXNzLiBJZiBwcm92aWRlciBwcm92aWRl cyB0aGUgcHVibGljIElQLG5vIG5lZWQgdG8gdXNlIHRoZSBsZWFmDQoNCiANCg0KU3RhdHVzICMx OiAgQ2xvc2VkIFBlbmRpbmcgSS1EIHRleHQgcmV2aWV3LiAgIA0KDQogDQoNCkRpc2N1c3Npb24g b24gIzE6IA0KDQogDQoNCiANCg0KQWlqdW4gYXNrcyBmb3IgbW9yZSBkZXNjcmlwdGlvbiBpbiB0 aGUgWUFORyBtb2RlbCBpdHNlbGYNCg0KIA0KDQpTdGVwaGFuZSBzaG93cyBjdXJyZW50IG1vZGVs DQoNCiANCg0KQWdyZWVkIE9LDQoNCiANCg0KIA0KDQpJc3N1ZSMyIDogSWRlbnRpZnkgbDN2cG4g c3ZjIHVzaW5nIGlkIG9yIG5hbWUgb3IgYm90aA0KDQogDQoNClJlc29sdXRpb24gIzI6ICBJRCBp cyBhIHN0cmluZywgYXMgcGVyIG90aGVyIHByb3BlcnRpZXMgaW4gdGhlIG1vZGVsDQoNCiANCg0K U3RhdHVzICMyOiBDbG9zZWQNCg0KIA0KDQpEaXNjdXNzaW9uIG9uICMyOiANCg0KIA0KDQogDQoN CkFncmVlZCBPSw0KDQogDQoNCiANCg0KSXNzdWUjMzogTSB0byBOIGF2YWlsYWJpbGl0eSBzdXBw b3J0DQoNCiANCg0KUmVzb2x1dGlvbiAjMzogTW9kZWxpbmcgc2l0ZXMgdXNpbmcgYSBsaXN0IHdp dGggYSBwcmlvcml0eSwgc28gaW5jbHVkZSBhY2Nlc3MgbGlzdCB3aXRoIGEgcHJpb3JpdHkuDQoN CiANCg0KU3RhdHVzICMzOg0KDQogDQoNCkRpc2N1c3Npb24gb24gIzM6IA0KDQogDQoNCiANCg0K UWluIHdhcyBhc2tpbmcgdGhhdCBNIHRvIE4gYXZhaWxhYmlsaXR5IGlzIHN1cHBvcnRlZCB3aXRo IGFjY2VzcyBhbmQgcHJpb3JpdHkgbnVtYmVyLiANCg0KIA0KDQpTdGVwaGFuZSBzdGF0ZWQgdGhp cyBpcyBzdXBwb3RlZC4gVGhpcyBuZXcgcHJvcG9zYWwgYWxzbyBzdXBwb3J0cyBtdWx0aXBsZSBz aXRlcywgYXMgYSBsaXN0Lg0KDQogDQoNClFpbiBhbHNvIGFza2VkIGlmIEdyb3VwIEktRCB3YXMg bm8gbG9uZ2VyIG5lZWRlZCwgd2hpY2ggaXQgaXMgbm90LiBBbHNvIGdvb2Qgc29sdXRpb24gc3Vw cG9ydGVkIGJ5IG90aGVyIG9wZXJhdG9ycy4NCg0KIA0KDQpTdGVwaGFuZSBhc2tlZCBpZiBmb3Vy IHByaW9yaXRpZXMgd2FzIGVub3VnaCwgb3IgaWYgbW9yZSB3ZXJlIG5lZWRlZC4gDQoNCiANCg0K IA0KDQpSZTogQ29udGFpbmVycy9Qcm9wZXJ0aWVzIGZvciBOZXR3b3JrIEFjY2VzcyBDb25maWd1 cmF0aW9uIC0gQ29uY2x1c2lvbnM/DQoNCiANCg0KIA0KDQpvIExvY2F0aW9uIC0gRGlmZmVyZW50 IHNpdGUgSS1EPw0KDQogDQoNCm8gUW9TIFBvbGljeSAtIFBlciBuZXR3b3JrIGFjY2VzcyBsaW5r LCBvciBzaXRlIGluZm9ybWF0aW9uPyBXb3VsZCBRb1MgKGNvc3QpIGJlIGRpZmZlcmVudCBwZXIg YWNjZXNzbGluayBvciBzaXRlPyBFeGFtcGxlIG9mIFByaW1hcnkgYW5kIEJhY2t1cCBsaW5rcyBn aXZlbi4gDQoNCiANCg0KbyBCYW5kd2lkdGggLSBNb3ZlZCB0byBhY2Nlc3MgbGluayBncm91cCAN Cg0KIA0KDQpvIE1heGltdW0gUm91dGVzIC0gDQoNCiANCg0KU2VjdXJpdHksIHJvdXRpbmcsIGFu ZCBzZXJ2aWNlcyBhcmUgZHVwbGljYXRlZCB3aXRoIGluaGVyaXRhbmNlDQoNCiANCg0KIA0KDQog DQoNCklzc3VlIzQ6IHNpdGUtc2VydmljZS1jbG91ZCBhY2Nlc3MgYXMgZ3JvdXBpbmcNCg0KIA0K DQpSZXNvbHV0aW9uICM0IEFscmVhZHkgcmVzaWx2ZWQgYXMgYSBzZXBhcmF0ZSBncm91cGluZw0K DQogDQoNClN0YXR1cyAjNDogQ2xvc2VkDQoNCiANCg0KRGlzY3Vzc2lvbiBvbiAjNDogDQoNCiAN Cg0KIA0KDQpJc3N1ZSM1OiBNdWx0aWNhc3Qgc3VwcG9ydCBhcyByYWlzZWQgYnkgRXJpYyBSb3Nl bg0KDQogDQoNClJlc29sdXRpb24gIzU6IDogTmV3ICJwcm92aWRlciBtYW5hZ2VkIiBwcm9wZXJ0 eSwgYW5kIGluIFNpdGUgUHJvcGVydGllcyAicHJvcGVydHktdHlwZSIgIGFkZGVkDQoNCiANCg0K U3RhdHVzICM1OiBTb2x1dGlvbiBwcm9wb3NlZC4gDQoNCiANCg0KRGlzY3Vzc2lvbiBvbiAjNTog DQoNCiANCg0KIA0KDQpTdGVwaGFuZSB3aWxsIHByb3Zpb2RlIG5ldyBwcm9wZXJ0eSBwcm9wb3Nh bHMgd2lsbCBiZSBwcm92aWRlZCB0byBFcmljIGZvciByZXZpZXcuIA0KDQogDQoNCiANCg0KSXNz dWUjNjogSW52ZW50b3J5IG9wZXJhdGlvbmFsIHN0YXRlDQoNCiANCg0KUmVzb2x1dGlvbiAjNjog SW5jbHVkZSBhIG5ldyBjb250YWluZXIgZm9yIGludmVudG9yeSBzdGF0ZSwgb3IgYW4gUlBDIGNh bGwgKHNpdHRpbmcgYWJvdmUgdGhlIHNlcnZpY2Ugb3JjaGVzdHJhdG9yKSB0byByZXRyaWV2ZSBp bnZlbnRvcnkgc3RhdGUuIA0KDQogDQoNClN0YXR1cyAjNjogTmVlZCB0byBwcm9wb3NlIHRvIHRo ZSBXRyBhbmQgYWdyZWUgc29sdXRpb24uDQoNCiANCg0KRGlzY3Vzc2lvbiBvbiAjNjogDQoNCiAN Cg0KIA0KDQpMdWlzIGFza2VkIHdvdWxkIHRoaXMgaW5mbyBiZSBjb2xsZWN0ZWQgZnJvbSBwcm92 aXNpb24gc3RhdGU/IFN0ZXBoYW5lIHN1Z2dlc3RlZCB0aGlzIHdvdWxkIG5vdCBiZSBhdmFpbGli bGUuIA0KDQogDQoNCkFkcmlhbiBvYnNlcnZlZCB0aGF0IHRoZSBjb2RlIHVzZWQgdG8gY29udmVy dCB0aGUgbW9kZWwgaW50byBhIHNlcnZpY2UgcmVxdWVzdCBtYXkgbm90IHV0aWxpc2UgdGhpcyBp bnZlbnRvcnkgaW5mb3JtYXRpb24gY2FwYWJpbGl0eS4gU3VlIG1lbnRpb25lZCB0aGF0IG90aGVy cyBoYXZlIG1lbnRpb25lZCBieSBhIHZlbmRvciB0aGF0IGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBo YXZlIHRoZSBhYmlsaXR5IHRvIGNvbmZpZ3VyZSBpbnZlbnRvcnkgc3RhdGUuIFRoaXMgc2hvdWxk IGJlIGNsYXJpZmllZCBieSB0aGUgb3BlcmF0b3JzLiANCg0KIA0KDQogDQoNClN0ZXBoYW5lIHRv IHRha2UgcHJvcG9zYWxzIHRvIGxpc3QgYW5kIGFzayBhbnlvbmUgd2hvIGlzIGludGVyZXN0ZWQg aW4gaGF2aW5nIHRoZSBmZWF0dXJlIHRvIHN1Z2dlc3QgdGV4dC4NCg0KIA0KDQogDQoNCiANCg0K SXNzdWUjNzogR2VuZXJpYyBWQVMgLSBkbyB3ZSBuZWVkIHRvIGNyZWF0ZSBhIGdlbmVyaWMgVkFT IGNvbnRhaW5lciBhcyBWQVMgYXJlIHBvcHVsYXIgaW4gTDNWUE5zPw0KDQogDQoNClJlc29sdXRp b24gIzc6IFNlcGFyYXRlIGZyb20gTDNTTQ0KDQogDQoNClN0YXR1cyAjNzogQ2xvc2VkDQoNCiAN Cg0KRGlzY3Vzc2lvbiBvbiAjNzogDQoNCiANCg0KIA0KDQpHdSBSb25nIGhpZ2hsaWdodGVkIEdl bmVyaWMgVkFTIG1vZGVsIHdoaWNoIHdhcyBwcmVzZW50ZWQgYXQgSUVURiA5NC4gDQoNCiANCg0K IA0KDQpJc3N1ZSM4OiBXaG8ga2VlcHMgc2l0ZSBsb2NhdGlvbmluZm9ybWF0aW9uPw0KDQogDQoN ClJlc29sdXRpb24gIzg6IFRleHQgaGFzIGJlZW4gZml4ZWQNCg0KIA0KDQpTdGF0dXMgIzg6IENs b3NlZA0KDQogDQoNCkRpc2N1c3Npb24gb24gIzg6IA0KDQogDQoNCiAgICANCg0KIA0KDQpJc3N1 ZSM5OiBEbyB3ZSBuZWVkIHRvIG1vZGVsIHRyYW5zcG9ydCBjb25zdHJhaW50cywgc3VjaCBhczog aml0dGVyLCBkaXNqb2ludCwgcGF0aCBkaXZlcnNpdHk/DQoNCiANCg0KUmVzb2x1dGlvbiAjOTog ICBQcm9wb3NlIGEgInRyYW5zcG9ydC1jb25zdHJhaW50IiBncm91cCB3aXRoICJjb25zdHJhaW50 LXR5cGUiLCAiY29uc3RyYWludC12YWx1ZSIgYW5kICJjb25zdHJhaW50LWxpc3QiIChjb21wb3Nl ZCBvZiB0eXBlIGFuZCB2YWx1ZXMpDQoNCiANCg0KU3RhdHVzICM5OiBBdXRob3JzIHRvIHByb3Bv c2UgdGhlIHJlc29sdXRpb24gaW4gdGhlIEktRCBhbmQgcHJvdmlkZSB0byB0aGUgV0cNCg0KIA0K DQpEaXNjdXNzaW9uIG9uICM5OiAgICANCg0KIA0KDQogDQoNCiANCg0KTHVpcyBtZW50aW9uZWQg dGhhdCB0aGV5IGhhdmUgbXVsdGljYXN0IHRyYW5zcG9ydCAobXVsdGlwbGUgc2l0ZXMpIGFuZCBi aS1kaXJlY3Rpb25hbCB0cmFmZmljIGFwcGxpY2F0aW9ucyAoZmluYW5jaWFsKSB0aGF0IHdpbGwg cmVxdWlyZSB0cmFuc3BvcnQgY29uc3RyYWludHMNCg0KIA0KDQogDQoNCkR1cGxpY2F0ZSB0cmFu c3BvcnQgY29uc3RyYWludHMgZm9yIHVuaWNhc3QgYW5kIG11bHRpY2FzdCB0byBnaXZlIG9wdGlv bnMgZm9yIHNlcGFyYXRlIGNvbmZpZ3VyYXRpb24uDQoNCiANCg0KS2VlcCBzaW5nbGUgbGlzdCBl bnRyaWVzIGZvciBlYWNoIHNyYy9kc3QgcGFpciBldmVuIGluIHRoZSBtdWx0aWNhc3QgdmFyaWFu dC4NCg0KIA0KDQogDQoNCkRPIHdlIG5lZWQgdG8gc3VwcG9ydCBtdWx0aXBsZSBjb25zdHJhaW50 cyBvciBqdXN0IGhhdmUgYSBzaW5nbGUgY29tcG9zaXRlIChvZiBtdWx0aXBsZSBjb25zdHJhaW50 cyksIGhhdmUgdGhlIGFiaWxpdHkgdG8gc3BlY2lmeSBhIGNvbnN0cmFpbnQtbGlzdD8NCg0KIA0K DQpBaWp1biBwcmZlcnMgbGlzdCBvZiBjb25zdHJhaW50cyBhbmQgbWVldGluZyBhZ3JlZXMgdGhp cyBpcyBPSw0KDQogDQoNCiANCg0KV2hhdCBjb25zdHJhaW50cyB0byBvZmZlcj8NCg0KIA0KDQpM YXRlbmN5DQoNCiANCg0KUGF0aCBkaXZlcnN0eQ0KDQogDQoNClNpdGUgZGl2ZXJzdHkNCg0KIA0K DQpKaXR0ZXINCg0KIA0KDQpDbGFzcyBvZiBzZXJ2aWNlIHdhcyBwcm9wb3NlZCBidXQgcmVqZWN0 ZWQNCg0KIA0KDQogDQoNCkx1aXMgaGlnaGxpZ2h0ZWQgdGhleSBoYXZlIGEgY3VycmVudCBpbXBs ZW1lbnRhdGlvbiB0aGF0IHVzZXMgdGhlIHNpbWlsYXIgcHJvcG9zYWwuIEx1aXMgYWxzbyBtZW50 aW9uZWQgdGhhdCBzaXRlIGRpdmVyc2l0eSBtaWdodCBhbHNvIGJlIHJlcXVpcmVkLCB3b3VsZCB0 aGlzIGJlIGFjaGlldmFibGUNCg0KIA0KDQogDQoNCiANCg0KSXNzdWUjMTA6IFZQTiAibWVyZ2lu ZyINCg0KIA0KDQpSZXNvbHV0aW9uICMxMDogICAgDQoNCiANCg0KU3RhdHVzICMxMDoNCg0KIA0K DQpEaXNjdXNzaW9uIG9uICMxMDogICAgDQoNCiANCg0KIA0KDQpWUE4gaXMgYSBwZXIgc2l0ZSBw cm9wZXJ0eS4gDQoNCiANCg0KLSBBIHNpdGUgY2FuIGJlbG9uZyB0b211bHRpcGxlIFZQTnMNCg0K IA0KDQotIEhvdyB0byBoYW5kbGUgbWVyZ2luZyBvZiB0d28gVlBOcz8NCg0KIA0KDQotIElzIHRo aXMgYW4gaXNzdWUgdGhlIHNlcnZpY2UgbW9kZWwgaGFzIHRvIGRlYWwgd2l0aD8NCg0KIA0KDQog DQoNCklmIFZQTiBtZXJnaW5nIGlzIHJlcXVpcmVkIHRvIGJlIHNlYW1sZXNzLCB0aGVuIHRoaXMg d291bGQgYmUgZGV2aWNlIHNwZWNpZmljIGFuZCBub3Qgc2VydmljZSBtb2RlbCByZWxhdGVkLiAg DQoNCiANCg0KIA0KDQoiTWVyZ2luZyIgaXMgYSBjb25mdXNpbmcgdGVybS4gVGhlIG9iamVjdGl2 ZSBpcyBOT1QgdG8gbWVyZ2UgVlBOMSBhbmQgVlBOMi4NCg0KIA0KDQpUaGUgb2JqZWN0aXZlIGlz IHRvIHByb3ZpZGUgYW4gZXh0cmFuZXQgc28gdGhhdCBzb21lIHNpdGVzIGluIFZQTjEgY2FuIGNv bm5lY3QgdG8gc29tZSBzaXRlcyBpbiBWUE4yIGZvciBzb21lIHRyYWZmaWMuDQoNCiANCg0KVGhp cyBjYW4gYmUgc29sdmVkIHVzaW5nIGEgcGVyLXNpdGUgcHJvcGVydHkuDQoNCiANCg0KIA0KDQpB Y3Rpb246IE5lZWQgdG8gdXBkYXRlIHRoaXMgaXNzdWUgdG8gbWFrZSBpdCBjbGVhciB3aGF0IGZ1 bmN0aW9uIHdhcyBiZWluZyBkaXNjdXNzZWQsIGFsc28gU3RlcGhhbmUgd2lsbCBzZW5kIG9wdGlv bnMgdG8gdGhlIHdvcmtpbmcgZ3JvdXAtIGxpc3QuIA0KDQogDQoNCldlIGFyZSBzcGVjaWZpY2Fs bHkgbG9va2luZyBmb3IgcGVvcGxlIHdobyBvZmZlciBleHRyYW5ldCBjb25uZWN0aW9uIGJldHdl ZW4gc2l0ZXMgZnJvbSBkaWZmZXJlbnQgVlBOcw0KDQogDQoNCiANCg0KPT0gT3RoZXIgSXNzdWVz ID09ICAgIA0KDQogDQoNCiANCg0KTW9kZWxpbmcgQ3VzdG9tZXIgU3BlY2lmaWMgSW5mbw0KDQog DQoNCi0gQ3JlYXRlIGFwcHJvcGlhdGUgY29udGFpbmVycyBmb3IgUHJvdmlkZXIgRWRnZSBhbmQg Q3VzdG9tZXIgU2l0ZSByb3V0ZXJzDQoNCiANCg0KLSBUaGUgY3VycmVudCAgbW9kZWwgY29udGFp bnMgcm91dGluZyBwYXJhbWV0cmVzIHRoYXQgcmVmZXIgdG8gQ0UgYW5kIFBFIHJlbGF0aW9uc2hp cHMNCg0KIA0KDQotIEdlbmVyYWwgYWdyZWVtZW50IGlzIHJvdXRpbmcgaW5mbyBzaG91bGQgYmUg c3BsaXQgYW5kIGN1cnJlbnQgcHJvcG9zYWwgd2lsbCBiZSBzZW50IHRvIHRoZSBsaXN0IGZvciBL ZW5pY2hpLCBhbmQgd29ya2luZyBncm91cHMsIHJldmlldy4gDQoNCiANCg0KIA0KDQo9PSBDb25j bHVzaW9ucyA9PQ0KDQogDQoNCiANCg0KLSBBIG51bWJlciBvZiByZXNvbHV0aW9ucyBoYXZlIGJl ZW4gYWdyZWVkIGFuZCB3aWxsIGJlIHVwZGF0ZWQgaW4gdGhlIEktRA0KDQogDQoNCi0gQ2hhaXJz IHdvdWxkIGxpa2UgdG8gc2VlIHJldmlzZWQgSS1EIGJhc2VkIG9uIHRoZSBhZ3JlZWQgcG9pbnRz DQoNCiANCg0KLSBQbGFuIHRvIGhhdmUgYW5vdGhlciBpbnRlcmltIGNhbGwgYXQgdGhlIGVuZCBv ZiBKYW51YXJ5ICgyMDE2KQ0KDQogDQoNCi0gQ2hhaXJzIHRvIGFkZCBuZXcgdHJhY2tlciBpdGVt cywgaW5jbHVkaW5nIHNlY3VyaXR5IGZvciBmdXR1cmUgZGlzY3Vzc2lvbi4gDQoNCiANCg0KIA0K DQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN Ckwzc20gbWFpbGluZyBsaXN0DQoNCkwzc21AaWV0Zi5vcmcgPG1haWx0bzpMM3NtQGlldGYub3Jn PiANCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtIDxodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20+IA0KDQogDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkwzc20gbWFpbGluZyBsaXN0 DQoNCkwzc21AaWV0Zi5vcmcgPG1haWx0bzpMM3NtQGlldGYub3JnPiANCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2wzc20+IA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KIA0KDQpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kNCg0K IA0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXphdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRl bGVjb20gLSBPcmFuZ2Ugc2hhbGwgbm90IGJlIGxpYWJsZSBpZiB0aGlzIG1lc3NhZ2Ugd2FzIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQogDQoNCiANCg0K IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCiANCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIEZyYW5jZSBUZWxlY29tIC0gT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpDQoNCiANCg0KVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcml6YXRpb24uDQoNCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIHNoYWxsIG5v dCBiZSBsaWFibGUgaWYgdGhpcyBtZXNzYWdlIHdhcyBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpMM3NtIG1haWxpbmcgbGlzdA0KDQpMM3NtQGlldGYub3Jn IDxtYWlsdG86TDNzbUBpZXRmLm9yZz4gDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbDNzbSA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3Nt PiANCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQpMM3NtIG1haWxpbmcgbGlzdA0KDQpMM3NtQGlldGYub3JnIDxtYWlsdG86TDNzbUBpZXRm Lm9yZz4gDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbSA8aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtPiANCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkwzc20gbWFpbGluZyBsaXN0DQpM M3NtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkwzc20g bWFpbGluZyBsaXN0DQpMM3NtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2wzc20NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkwzc20gbWFpbGluZyBsaXN0DQpMM3NtQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkwzc20gbWFpbGluZyBsaXN0DQpMM3NtQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20NCg== From nobody Wed Feb 24 23:00:09 2016 Return-Path: <13301168517@189.cn> X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A888B1B3458 for ; Wed, 24 Feb 2016 23:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.895 X-Spam-Level: ** X-Spam-Status: No, score=2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_LOCAL_DIGITS=0.001, FROM_LOCAL_HEX=0.006, HELO_IS_SMALL6=0.556, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 FtGcQFlfQwdU for ; Wed, 24 Feb 2016 23:00:04 -0800 (PST) Received: from 189.cn (mta.189.cn [121.14.53.140]) by ietfa.amsl.com (Postfix) with ESMTP id 338AE1B342B for ; Wed, 24 Feb 2016 23:00:02 -0800 (PST) HMM_SOURCE_IP: 10.64.8.33:51984.253780124 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.77 (unknown [10.64.8.33]) by 189.cn (HERMES) with ESMTP id C554311C0EC; Thu, 25 Feb 2016 14:59:59 +0800 (CST) Received: from ctbriwangaij ([219.142.69.77]) by zm-as3(MEDUSA 0.0.0.0) with ESMTP id 1b1654fb-5780-4f66-ac76-305662b910d2 for bill.wu@huawei.com; Thu Feb 25 15:00:01 2016 0/X-Total-Score: 0: X-FILTER-SCORE: to=<838a8d8d4f98966189968298868a4f84908e>, score=<1456383601qoEEEEEDEEBEEVEDBV4XJsgXXXXXeXXCXX8XeC8GkMDO> X-REAL-FROM: 13301168517@189.cn X-Receive-IP: 219.142.69.77 From: "Aijun Wang" <13301168517@189.cn> To: "'Ogaki, Kenichi'" , "'Qin Wu'" , , References: <11137_1452868271_569902AF_11137_18933_1_9E32478DFA9976438E7A22F69B08FF921683F2D0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <009a01d1518a$dccd16e0$966744a0$@kddi.com> <28946_1453107612_569CA99C_28946_1310_1_9E32478DFA9976438E7A22F69B08FF921683F60F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <000001d15266$38428380$a8c78a80$@kddi.com> <002c01d16d15$fb50c390$f1f24ab0$@kddi.com> <018d01d16f88$2776fd80$7664f880$@kddi.com> In-Reply-To: <018d01d16f88$2776fd80$7664f880$@kddi.com> Date: Thu, 25 Feb 2016 15:00:15 +0800 Message-ID: <009301d16f9a$2fe4de30$8fae9a90$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQH5Bq8eqk2F/jjoJjePPJmqqbPofQJPFi+8Aw+DAN8BzQ7zqQKVjWu7AxyabOmehhEagIAAJSUA Content-Language: zh-cn Archived-At: Subject: Re: [L3sm] Modeling a site with multiple subsites X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 07:00:07 -0000 Hi, Ogaki: Not only the site-network-access is related to specific vpn, almost most = of the site's parameters are all vpn related. I mentioned also this issue = in https://mailarchive.ietf.org/arch/msg/l3sm/Hh4F8c8O2njayv3TWnZMmh5W3uY It seems we can solve such problem when we put the list site within the = list "vpn-svc". Best Regards. -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 25, 2016 12:51 PM To: 'Qin Wu'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi Qin, >Support subVPN case or multiple network accesses that is not for multihoming? Not for multihoming from a site to a single VPN(or under a single vpn-policy). The current model can only differentiate vpn-policy per sites. But, = there are many use cases to require vpn-policy per site-network-access. You can find the current limitation and use cases on the exchanges in = this thread. >I believe this issue is separated from what we discussed earlier about extranet VPN policy. Yes, this is different issue. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu Sent: Thursday, February 25, 2016 12:57 PM To: Ogaki, Kenichi; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Kenichi: Can you clarify a little bit the objective of the following proposal? Support subVPN case or multiple network accesses that is not for multihoming? I believe this issue is separated from what we discussed earlier about extranet VPN policy. -Qin -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: L3sm [mailto:l3sm-bounces@ietf.org] =B4=FA=B1=ED = Ogaki, Kenichi =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C222=C8=D5 10:09 =CA=D5=BC=FE=C8=CB: stephane.litkowski@orange.com; l3sm@ietf.org =D6=F7=CC=E2: Re: [L3sm] Modeling a site with multiple subsites Hi Stephane and All, >>How to you differentiate multihoming from your subVPN case? they are=20 >>two different >things. >As I wrote, we just have to *duplicate* vpn-policy under=20 >site-network-access. When an operator's use case requires multiVPN,=20 >then vpn-policy should be under sites as the current model does. >When the other operator requires subVPN, vpn-policy should just be=20 >under site- network-access. It's sufficient to use these two cases exclusively. Here is a minimum modification proposal to the current model in order to = use these two cases exclusively. Only if a vpn-policy is not defined directly under sites, we can define = it under site-network-access. If something is grammatically wrong in terms of YANG and XPATH = expression, could anyone correct me? ... container site-network-accesses { list site-network-access { uses site-vpn-policy { refine vpn-policy { when "not(../../../vpn-policy)"; } } ... } ... } ... Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Tuesday, January 19, 2016 12:05 PM To: stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi Stephane, >We cannot use site-network-access which is used for multihoming only. Why do we have to use site-network-access only for multihoming? This is intuitively mapped to a logical access as you wrote. >How to you differentiate multihoming from your subVPN case? they are = two different things. As I wrote, we just have to *duplicate* vpn-policy under site-network-access. When an operator's use case requires multiVPN, then vpn-policy should be under sites as the current model does. When the other operator requires subVPN, vpn-policy should just be under site-network-access. It's sufficient to use these two cases exclusively. >Could you provide more technical detail so I will be able to understand what exactly you are trying to achieve ? Our existing commercial service allows the *logically* following = diagram. PE1, PE2 and PE3 can be VRFs inside a single physical PE, or may be physically separate PEs. Same as CEs. L2SW can be QinQ sub-interfaces on = a single physical PE depending on the above case. Then, we may map each element like this. sites: A customer premises connected via QinQ (stag 100) sub-sites: A customer premises' layer 2 segment separated by .1Q (ctag = 10 or 20), a ctag segment can include multiple logical accesses with bgp peer = per logical access. For example, PE1 has a bgp peer with CE1, and PE2 has a different bgp peer with CE2. In this case, when VPN X only talks to LAN X, we need subVPN inside sub-sites. But, we can deal with a sub-sites as a sites for the = simplicity to minimally extend the current model. Even so, we still need vpn-policy = per site-network-access. +-----------------------------+ +------------------------------+ | | | | | /---\ ctag 10 | | ctag 10 /---\ | | VPN A-+ PE1 +--------+ | | +--------+ CE1 +-LAN A | | \---/ | | | | \---/ | | | | | | | | /---\ctag 10+-+----+ |stag 100| +----+-+ctag 10/---\ | | VPN B-+ PE2 +------+ L2SW +-+--------+-+ L2SW +------+ CE2 +-LAN B | | \---/ +-+----+ | | +----+-+ \---/ | | | | | | | | /---\ctag 20 | | | | ctag 20 /---\ | | VPN C-+ PE3 +--------+ | | +--------+ CE3 +-LAN C | | \---/ | | \---/ | | | | | +-----------------------------+ +------------------------------+ Central Office Customer Premises All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com Sent: Monday, January 18, 2016 6:00 PM To: Ogaki, Kenichi; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi, We cannot use site-network-access which is used for multihoming only. How to you differentiate multihoming from your subVPN case ? they are = two different things. So I'm completely against using site-network-accesses as a subVPN can be also multihomed ... > FYI, our commercial service honestly has a similar element as = sub-sites, corresponding to vlan, but we still allows multiple vpns and bgp peers, = each different vpn access per peer, within a single vlan. Could you provide more technical detail so I will be able to understand = what exactly you are trying to achieve ? Best Regards, Stephane -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Monday, January 18, 2016 01:55 To: LITKOWSKI Stephane SCE/OINIS; l3sm@ietf.org Subject: RE: [L3sm] Modeling a site with multiple subsites Hi Stephane, >Single "physical" access between SP and customer, but multiple = sub-accesses on top (VLAN, PPP sessions, or whatever ...), each one pointing to a specific VPN. As you wrote above in the scenario a) and b), vpn-policy only have to be controlled per logical access, equivalent to the site-network-access in = the current model. To solve the issue as simple as possible, it's sufficient = to duplicate vpn-policy under site-network-access. In these cases, a completely different conceptual element, sub-sites, is = not required. This must bring a complexity, and sometimes hard to be = understood, depending on operator's usecase.=20 Although we shouldn't discuss the device modelling, the granularity of sub-sites corresponds to a VRF's one from the viewpoint of vpn-policy. = In this case, nobody intuitively imagines (sub-)sites from VRF, because = it's commonly in a single physical box. FYI, our commercial service honestly has a similar element as sub-sites, corresponding to vlan, but we still allows multiple vpns and bgp peers, = each different vpn access per peer, within a single vlan. All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com Sent: Friday, January 15, 2016 11:31 PM To: l3sm@ietf.org Subject: [L3sm] Modeling a site with multiple subsites [Creating another topic for better followup] =20 Today the model has the ability to create sites, a site can be = multihomed to the network thanks to the site-network-access sub-tree. =20 Now the question is how to we model such scenarios : =20 a) "SUBVPN case" : Single "physical" access between SP and = customer, but multiple sub-accesses on top (VLAN, PPP sessions, or whatever .), = each one pointing to a specific VPN. It is expected for the customer to = ensure flow separation (VRF lite, VLANs .). It's typically a big company with a = Hub site used where affiliates have dedicated resources in the Hub site, and affiliates must not talk to each other or even share resources. Note = that I putted "physical" between quotes because it can be a nested logical = accesses . =20 =20 b) "INTER-AS option A like " case : this is the back to back VRF = case, as previously single "physical" access and multiple logical accesses on = top each one pointing to a separate VPN. I putted interAS, but this can be "intra-AS" with iBGP back to back VRFs also (internal DC for example) =20 c) What about option B ? Do we consider option B as a service ? I would not be in favor of that. Option B setups are really particular in = term of design, security . So I would like to have option B out of scope. =20 =20 Even if a) and b) are separated use cases from a service point of view, these are similar in term of modeling. =20 Today we can model it has a collection of separated sites without any relationship between each other. The other point is that we cannot = express any property of the "physical" attachment but there may few (encryption = ?). We can keep the model as it is with this limitation or we can create = site and sub-site hierarchy which as I already said may complexify the = reading and usability (IMO). It may look like this : =20 =A1=A4 Sites o Site-only-parameters : =A1=EC Location =A1=EC Diversity =A1=EC management =A1=EC Security o Specific-parameters : <- to be used only if there is no subsite. =A1=EC Vpn-policy =A1=EC Services =A1=EC Routing-protocols =A1=EC Site-network-accesses =A1=A4 .. o Sub-sites : <- to be used in case of sub sites present =A1=EC Specific-parameters : =A1=A4 Vpn-policy =A1=A4 Services =A1=A4 Routing-protocols =A1=A4 Site-network-accesses o . =20 I'm also wondering if bearer parameters must also be taken out in this = case and putted in the site-only-parameters.=20 The hierarchy becomes really complex here and I would like to keep it as simple as possible. =20 =20 Would be good to have multiple feedbacks from the WG to see where the consensus is. =20 =20 Orange logo =20 =20 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 =20 =20 =20 _________________________________________________________________________= ___ _____________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 From nobody Wed Feb 24 23:24:23 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA57F1A6EDB for ; Wed, 24 Feb 2016 23:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 8LNK587NFWVX for ; Wed, 24 Feb 2016 23:24:17 -0800 (PST) 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 F31541A016A for ; Wed, 24 Feb 2016 23:24:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEZ07246; Thu, 25 Feb 2016 07:24:14 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 07:24:13 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 15:24:09 +0800 From: Qin Wu To: Aijun Wang <13301168517@189.cn>, "'Ogaki, Kenichi'" , "stephane.litkowski@orange.com" , "l3sm@ietf.org" Thread-Topic: [L3sm] Modeling a site with multiple subsites Thread-Index: AdFPnqCmtWfFPEtQT6m/5Yx5kcaoDABqSt8AABDyLYAAJeSogAar8U0AAKsvQfD//4regIAAJA2A//91RNA= Date: Thu, 25 Feb 2016 07:24:08 +0000 Message-ID: References: <11137_1452868271_569902AF_11137_18933_1_9E32478DFA9976438E7A22F69B08FF921683F2D0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <009a01d1518a$dccd16e0$966744a0$@kddi.com> <28946_1453107612_569CA99C_28946_1310_1_9E32478DFA9976438E7A22F69B08FF921683F60F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <000001d15266$38428380$a8c78a80$@kddi.com> <002c01d16d15$fb50c390$f1f24ab0$@kddi.com> <018d01d16f88$2776fd80$7664f880$@kddi.com> <009301d16f9a$2fe4de30$8fae9a90$@cn> In-Reply-To: <009301d16f9a$2fe4de30$8fae9a90$@cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.208] 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.0A020206.56CEAC1F.0095, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0fc334dc862f576fa83551b6ce03c7ca Archived-At: Subject: Re: [L3sm] Modeling a site with multiple subsites X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 07:24:21 -0000 SW50ZXJlc3RpbmcsIG9uZSBxdWVzdGlvbiBJIHdhbnQgdG8gYXNrIGhlcmUgd2hlbiB3ZSBtb2Rl bCA1IHNpdGVzIGJlbG9uZ2luZyB0byAzIGRpZmZlcmVudCBWUE4sIGRvIHdlIG1vZGVsIHRoZW0g dXNpbmcgYSBzaW5nbGUgc2VydmljZSBtb2RlbCBvciBkbyB3ZSBjcmVhdGUgMyBzZXJ2aWNlIG1v ZGVscyB3aXRoIGVhY2ggbW9kZWxpbmcgb25lIFZQTj8gSW4gb3JkZXIgd29yZHMsIGRvIHdlIG5l ZWQgdG8gZGVmaW5lIGEgbGlzdCBvZiBWUE5zIGZvciB0aGUgVlBOIHNlcnZpY2UgY29ycmVzcG9u ZGluZyB0byBhIHNwZWNpZmljIGN1c3RvbWVyIGluIGEgc2luZ2xlIG1vZGVsPw0KDQotUWluDQot LS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogQWlqdW4gV2FuZyBbbWFpbHRvOjEzMzAxMTY4NTE3 QDE4OS5jbl0gDQq3osvNyrG85DogMjAxNsTqMtTCMjXI1SAxNTowMA0KytW8/sjLOiAnT2dha2ks IEtlbmljaGknOyBRaW4gV3U7IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBsM3NtQGll dGYub3JnDQrW98ziOiBSRTogW0wzc21dIE1vZGVsaW5nIGEgc2l0ZSB3aXRoIG11bHRpcGxlIHN1 YnNpdGVzDQoNCkhpLCBPZ2FraToNCg0KTm90IG9ubHkgdGhlIHNpdGUtbmV0d29yay1hY2Nlc3Mg aXMgcmVsYXRlZCB0byBzcGVjaWZpYyB2cG4sIGFsbW9zdCBtb3N0IG9mIHRoZSBzaXRlJ3MgcGFy YW1ldGVycyBhcmUgYWxsIHZwbiByZWxhdGVkLiBJIG1lbnRpb25lZCBhbHNvIHRoaXMgaXNzdWUg aW4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9sM3NtL0hoNEY4YzhPMm5q YXl2M1RXblpNbWg1VzN1WQ0KSXQgc2VlbXMgd2UgY2FuIHNvbHZlIHN1Y2ggcHJvYmxlbSB3aGVu IHdlIHB1dCB0aGUgbGlzdCBzaXRlIHdpdGhpbiB0aGUgbGlzdCAidnBuLXN2YyIuDQoNCkJlc3Qg UmVnYXJkcy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEwzc20gW21haWx0 bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBPZ2FraSwgS2VuaWNoaQ0KU2Vu dDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI1LCAyMDE2IDEyOjUxIFBNDQpUbzogJ1FpbiBXdSc7IHN0 ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W0wzc21dIE1vZGVsaW5nIGEgc2l0ZSB3aXRoIG11bHRpcGxlIHN1YnNpdGVzDQoNCkhpIFFpbiwN Cg0KPlN1cHBvcnQgc3ViVlBOIGNhc2Ugb3IgbXVsdGlwbGUgbmV0d29yayBhY2Nlc3NlcyB0aGF0 IGlzIG5vdCBmb3INCm11bHRpaG9taW5nPw0KDQpOb3QgZm9yIG11bHRpaG9taW5nIGZyb20gYSBz aXRlIHRvIGEgc2luZ2xlIFZQTihvciB1bmRlciBhIHNpbmdsZSB2cG4tcG9saWN5KS4NClRoZSBj dXJyZW50IG1vZGVsIGNhbiBvbmx5IGRpZmZlcmVudGlhdGUgdnBuLXBvbGljeSBwZXIgc2l0ZXMu IEJ1dCwgdGhlcmUgYXJlIG1hbnkgdXNlIGNhc2VzIHRvIHJlcXVpcmUgdnBuLXBvbGljeSBwZXIg c2l0ZS1uZXR3b3JrLWFjY2Vzcy4NCllvdSBjYW4gZmluZCB0aGUgY3VycmVudCBsaW1pdGF0aW9u IGFuZCB1c2UgY2FzZXMgb24gdGhlIGV4Y2hhbmdlcyBpbiB0aGlzIHRocmVhZC4NCg0KPkkgYmVs aWV2ZSB0aGlzIGlzc3VlIGlzIHNlcGFyYXRlZCBmcm9tIHdoYXQgd2UgZGlzY3Vzc2VkIGVhcmxp ZXIgYWJvdXQNCmV4dHJhbmV0IFZQTiBwb2xpY3kuDQpZZXMsIHRoaXMgaXMgZGlmZmVyZW50IGlz c3VlLg0KDQpUaGFua3MsDQpLZW5pY2hpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUWlu IFd1DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjUsIDIwMTYgMTI6NTcgUE0NClRvOiBPZ2Fr aSwgS2VuaWNoaTsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbTDNzbV0gTW9kZWxpbmcgYSBzaXRlIHdpdGggbXVsdGlwbGUgc3Vic2l0 ZXMNCg0KS2VuaWNoaToNCkNhbiB5b3UgY2xhcmlmeSBhIGxpdHRsZSBiaXQgdGhlIG9iamVjdGl2 ZSBvZiB0aGUgZm9sbG93aW5nIHByb3Bvc2FsPw0KU3VwcG9ydCBzdWJWUE4gY2FzZSBvciBtdWx0 aXBsZSBuZXR3b3JrIGFjY2Vzc2VzIHRoYXQgaXMgbm90IGZvciBtdWx0aWhvbWluZz8NCkkgYmVs aWV2ZSB0aGlzIGlzc3VlIGlzIHNlcGFyYXRlZCBmcm9tIHdoYXQgd2UgZGlzY3Vzc2VkIGVhcmxp ZXIgYWJvdXQgZXh0cmFuZXQgVlBOIHBvbGljeS4NCg0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0t DQq3orz+yMs6IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gT2dha2ks IEtlbmljaGkNCreiy83KsbzkOiAyMDE2xOoy1MIyMsjVIDEwOjA5DQrK1bz+yMs6IHN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQrW98ziOiBSZTogW0wzc21dIE1v ZGVsaW5nIGEgc2l0ZSB3aXRoIG11bHRpcGxlIHN1YnNpdGVzDQoNCkhpIFN0ZXBoYW5lIGFuZCBB bGwsDQoNCj4+SG93IHRvIHlvdSBkaWZmZXJlbnRpYXRlIG11bHRpaG9taW5nIGZyb20geW91ciBz dWJWUE4gY2FzZT8gdGhleSBhcmUgDQo+PnR3byBkaWZmZXJlbnQNCj50aGluZ3MuDQoNCj5BcyBJ IHdyb3RlLCB3ZSBqdXN0IGhhdmUgdG8gKmR1cGxpY2F0ZSogdnBuLXBvbGljeSB1bmRlciANCj5z aXRlLW5ldHdvcmstYWNjZXNzLiBXaGVuIGFuIG9wZXJhdG9yJ3MgdXNlIGNhc2UgcmVxdWlyZXMg bXVsdGlWUE4sIA0KPnRoZW4gdnBuLXBvbGljeSBzaG91bGQgYmUgdW5kZXIgc2l0ZXMgYXMgdGhl IGN1cnJlbnQgbW9kZWwgZG9lcy4NCj5XaGVuIHRoZSBvdGhlciBvcGVyYXRvciByZXF1aXJlcyBz dWJWUE4sIHZwbi1wb2xpY3kgc2hvdWxkIGp1c3QgYmUgDQo+dW5kZXIgc2l0ZS0gbmV0d29yay1h Y2Nlc3MuIEl0J3Mgc3VmZmljaWVudCB0byB1c2UgdGhlc2UgdHdvIGNhc2VzDQpleGNsdXNpdmVs eS4NCg0KSGVyZSBpcyBhIG1pbmltdW0gbW9kaWZpY2F0aW9uIHByb3Bvc2FsIHRvIHRoZSBjdXJy ZW50IG1vZGVsIGluIG9yZGVyIHRvIHVzZSB0aGVzZSB0d28gY2FzZXMgZXhjbHVzaXZlbHkuDQpP bmx5IGlmIGEgdnBuLXBvbGljeSBpcyBub3QgZGVmaW5lZCBkaXJlY3RseSB1bmRlciBzaXRlcywg d2UgY2FuIGRlZmluZSBpdCB1bmRlciBzaXRlLW5ldHdvcmstYWNjZXNzLg0KSWYgc29tZXRoaW5n IGlzIGdyYW1tYXRpY2FsbHkgd3JvbmcgaW4gdGVybXMgb2YgWUFORyBhbmQgWFBBVEggZXhwcmVz c2lvbiwgY291bGQgYW55b25lIGNvcnJlY3QgbWU/DQoNCi4uLg0KY29udGFpbmVyIHNpdGUtbmV0 d29yay1hY2Nlc3NlcyB7DQogICAgbGlzdCBzaXRlLW5ldHdvcmstYWNjZXNzIHsNCiAgICAgICAg dXNlcyBzaXRlLXZwbi1wb2xpY3kgew0KICAgICAgICAgICAgcmVmaW5lIHZwbi1wb2xpY3kgew0K ICAgICAgICAgICAgICAgIHdoZW4gIm5vdCguLi8uLi8uLi92cG4tcG9saWN5KSI7DQogICAgICAg ICAgICB9DQogICAgICAgIH0NCiAgICAuLi4NCiAgICB9DQouLi4NCn0NCi4uLg0KDQpUaGFua3Ms DQpLZW5pY2hpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMM3NtIFttYWls dG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2dha2ksIEtlbmljaGkNClNl bnQ6IFR1ZXNkYXksIEphbnVhcnkgMTksIDIwMTYgMTI6MDUgUE0NClRvOiBzdGVwaGFuZS5saXRr b3dza2lAb3JhbmdlLmNvbTsgbDNzbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtMM3NtXSBNb2Rl bGluZyBhIHNpdGUgd2l0aCBtdWx0aXBsZSBzdWJzaXRlcw0KDQpIaSBTdGVwaGFuZSwNCg0KPldl IGNhbm5vdCB1c2Ugc2l0ZS1uZXR3b3JrLWFjY2VzcyB3aGljaCBpcyB1c2VkIGZvciBtdWx0aWhv bWluZyBvbmx5Lg0KDQpXaHkgZG8gd2UgaGF2ZSB0byB1c2Ugc2l0ZS1uZXR3b3JrLWFjY2VzcyBv bmx5IGZvciBtdWx0aWhvbWluZz8gVGhpcyBpcyBpbnR1aXRpdmVseSBtYXBwZWQgdG8gYSBsb2dp Y2FsIGFjY2VzcyBhcyB5b3Ugd3JvdGUuDQoNCg0KPkhvdyB0byB5b3UgZGlmZmVyZW50aWF0ZSBt dWx0aWhvbWluZyBmcm9tIHlvdXIgc3ViVlBOIGNhc2U/IHRoZXkgYXJlIA0KPnR3bw0KZGlmZmVy ZW50IHRoaW5ncy4NCg0KQXMgSSB3cm90ZSwgd2UganVzdCBoYXZlIHRvICpkdXBsaWNhdGUqIHZw bi1wb2xpY3kgdW5kZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzcy4gV2hlbiBhbiBvcGVyYXRvcidzIHVz ZSBjYXNlIHJlcXVpcmVzIG11bHRpVlBOLCB0aGVuIHZwbi1wb2xpY3kgc2hvdWxkIGJlIHVuZGVy IHNpdGVzIGFzIHRoZSBjdXJyZW50IG1vZGVsIGRvZXMuDQpXaGVuIHRoZSBvdGhlciBvcGVyYXRv ciByZXF1aXJlcyBzdWJWUE4sIHZwbi1wb2xpY3kgc2hvdWxkIGp1c3QgYmUgdW5kZXIgc2l0ZS1u ZXR3b3JrLWFjY2Vzcy4gSXQncyBzdWZmaWNpZW50IHRvIHVzZSB0aGVzZSB0d28gY2FzZXMgZXhj bHVzaXZlbHkuDQoNCg0KPkNvdWxkIHlvdSBwcm92aWRlIG1vcmUgdGVjaG5pY2FsIGRldGFpbCBz byBJIHdpbGwgYmUgYWJsZSB0byB1bmRlcnN0YW5kDQp3aGF0IGV4YWN0bHkgeW91IGFyZSB0cnlp bmcgdG8gYWNoaWV2ZSA/DQoNCk91ciBleGlzdGluZyBjb21tZXJjaWFsIHNlcnZpY2UgYWxsb3dz IHRoZSAqbG9naWNhbGx5KiBmb2xsb3dpbmcgZGlhZ3JhbS4NClBFMSwgUEUyIGFuZCBQRTMgY2Fu IGJlIFZSRnMgaW5zaWRlIGEgc2luZ2xlIHBoeXNpY2FsIFBFLCBvciBtYXkgYmUgcGh5c2ljYWxs eSBzZXBhcmF0ZSBQRXMuIFNhbWUgYXMgQ0VzLiBMMlNXIGNhbiBiZSBRaW5RIHN1Yi1pbnRlcmZh Y2VzIG9uIGEgc2luZ2xlIHBoeXNpY2FsIFBFIGRlcGVuZGluZyBvbiB0aGUgYWJvdmUgY2FzZS4N Cg0KVGhlbiwgd2UgbWF5IG1hcCBlYWNoIGVsZW1lbnQgbGlrZSB0aGlzLg0KDQpzaXRlczogQSBj dXN0b21lciBwcmVtaXNlcyBjb25uZWN0ZWQgdmlhIFFpblEgKHN0YWcgMTAwKQ0Kc3ViLXNpdGVz OiBBIGN1c3RvbWVyIHByZW1pc2VzJyBsYXllciAyIHNlZ21lbnQgc2VwYXJhdGVkIGJ5IC4xUSAo Y3RhZyAxMCBvciAyMCksIGEgY3RhZyBzZWdtZW50IGNhbiBpbmNsdWRlIG11bHRpcGxlIGxvZ2lj YWwgYWNjZXNzZXMgd2l0aCBiZ3AgcGVlciBwZXIgbG9naWNhbCBhY2Nlc3MuIEZvciBleGFtcGxl LCBQRTEgaGFzIGEgYmdwIHBlZXIgd2l0aCBDRTEsIGFuZCBQRTIgaGFzIGEgZGlmZmVyZW50IGJn cCBwZWVyIHdpdGggQ0UyLg0KDQpJbiB0aGlzIGNhc2UsIHdoZW4gVlBOIFggb25seSB0YWxrcyB0 byBMQU4gWCwgd2UgbmVlZCBzdWJWUE4gaW5zaWRlIHN1Yi1zaXRlcy4gQnV0LCB3ZSBjYW4gZGVh bCB3aXRoIGEgc3ViLXNpdGVzIGFzIGEgc2l0ZXMgZm9yIHRoZSBzaW1wbGljaXR5IHRvIG1pbmlt YWxseSBleHRlbmQgdGhlIGN1cnJlbnQgbW9kZWwuIEV2ZW4gc28sIHdlIHN0aWxsIG5lZWQgdnBu LXBvbGljeSBwZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzcy4NCg0KKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQp8ICAgICAgICAvLS0tXCBjdGFnIDEwICAgICAgICB8ICAgICAgICB8ICAgICAg ICBjdGFnIDEwIC8tLS1cICAgICAgICAgfA0KfCBWUE4gQS0rIFBFMSArLS0tLS0tLS0rICAgICAg fCAgICAgICAgfCAgICAgICstLS0tLS0tLSsgQ0UxICstTEFOIEEgIHwNCnwgICAgICAgIFwtLS0v ICAgICAgICAgfCAgICAgIHwgICAgICAgIHwgICAgICB8ICAgICAgICAgXC0tLS8gICAgICAgICB8 DQp8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgICB8ICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgfA0KfCAgICAgICAgLy0tLVxjdGFnIDEwKy0rLS0tLSsgfHN0YWcgMTAw fCArLS0tLSstK2N0YWcgMTAvLS0tXCAgICAgICAgIHwNCnwgVlBOIEItKyBQRTIgKy0tLS0tLSsg TDJTVyArLSstLS0tLS0tLSstKyBMMlNXICstLS0tLS0rIENFMiArLUxBTiBCICB8DQp8ICAgICAg ICBcLS0tLyAgICAgICArLSstLS0tKyB8ICAgICAgICB8ICstLS0tKy0rICAgICAgIFwtLS0vICAg ICAgICAgfA0KfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAgICAgICAgfCAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgIHwNCnwgICAgICAgIC8tLS1cY3RhZyAyMCAgfCAgICAgIHwg ICAgICAgIHwgICAgICB8IGN0YWcgMjAgLy0tLVwgICAgICAgICB8DQp8IFZQTiBDLSsgUEUzICst LS0tLS0tLSsgICAgICB8ICAgICAgICB8ICAgICAgKy0tLS0tLS0tKyBDRTMgKy1MQU4gQyAgfA0K fCAgICAgICAgXC0tLS8gICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICBc LS0tLyAgICAgICAgIHwNCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAg Q2VudHJhbCBPZmZpY2UgICAgICAgICAgICAgICAgICAgICAgICBDdXN0b21lciBQcmVtaXNlcw0K DQpBbGwgdGhlIGJlc3QsDQpLZW5pY2hpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygc3Rl cGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxOCwgMjAx NiA2OjAwIFBNDQpUbzogT2dha2ksIEtlbmljaGk7IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbTDNzbV0gTW9kZWxpbmcgYSBzaXRlIHdpdGggbXVsdGlwbGUgc3Vic2l0ZXMNCg0KSGksDQoN CldlIGNhbm5vdCB1c2Ugc2l0ZS1uZXR3b3JrLWFjY2VzcyB3aGljaCBpcyB1c2VkIGZvciBtdWx0 aWhvbWluZyBvbmx5Lg0KSG93IHRvIHlvdSBkaWZmZXJlbnRpYXRlIG11bHRpaG9taW5nIGZyb20g eW91ciBzdWJWUE4gY2FzZSA/IHRoZXkgYXJlIHR3byBkaWZmZXJlbnQgdGhpbmdzLg0KU28gSSdt IGNvbXBsZXRlbHkgYWdhaW5zdCB1c2luZyBzaXRlLW5ldHdvcmstYWNjZXNzZXMgYXMgYSBzdWJW UE4gY2FuIGJlIGFsc28gbXVsdGlob21lZCAuLi4NCg0KPiBGWUksIG91ciBjb21tZXJjaWFsIHNl cnZpY2UgaG9uZXN0bHkgaGFzIGEgc2ltaWxhciBlbGVtZW50IGFzIA0KPiBzdWItc2l0ZXMsDQpj b3JyZXNwb25kaW5nIHRvIHZsYW4sIGJ1dCB3ZSBzdGlsbCBhbGxvd3MgbXVsdGlwbGUgdnBucyBh bmQgYmdwIHBlZXJzLCBlYWNoIGRpZmZlcmVudCB2cG4gYWNjZXNzIHBlciBwZWVyLCB3aXRoaW4g YSBzaW5nbGUgdmxhbi4NCkNvdWxkIHlvdSBwcm92aWRlIG1vcmUgdGVjaG5pY2FsIGRldGFpbCBz byBJIHdpbGwgYmUgYWJsZSB0byB1bmRlcnN0YW5kIHdoYXQgZXhhY3RseSB5b3UgYXJlIHRyeWlu ZyB0byBhY2hpZXZlID8NCg0KQmVzdCBSZWdhcmRzLA0KDQpTdGVwaGFuZQ0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPZ2FraSwgS2VuaWNoaSBbbWFpbHRvOmtlLW9vZ2Fr aUBrZGRpLmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxOCwgMjAxNiAwMTo1NQ0KVG86IExJ VEtPV1NLSSBTdGVwaGFuZSBTQ0UvT0lOSVM7IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBb TDNzbV0gTW9kZWxpbmcgYSBzaXRlIHdpdGggbXVsdGlwbGUgc3Vic2l0ZXMNCg0KSGkgU3RlcGhh bmUsDQoNCj5TaW5nbGUgInBoeXNpY2FsIiBhY2Nlc3MgYmV0d2VlbiBTUCBhbmQgY3VzdG9tZXIs IGJ1dCBtdWx0aXBsZSANCj5zdWItYWNjZXNzZXMNCm9uIHRvcCAoVkxBTiwgUFBQIHNlc3Npb25z LCBvciB3aGF0ZXZlciAuLi4pLCBlYWNoIG9uZSBwb2ludGluZyB0byBhIHNwZWNpZmljIFZQTi4N Cg0KQXMgeW91IHdyb3RlIGFib3ZlIGluIHRoZSBzY2VuYXJpbyBhKSBhbmQgYiksIHZwbi1wb2xp Y3kgb25seSBoYXZlIHRvIGJlIGNvbnRyb2xsZWQgcGVyIGxvZ2ljYWwgYWNjZXNzLCBlcXVpdmFs ZW50IHRvIHRoZSBzaXRlLW5ldHdvcmstYWNjZXNzIGluIHRoZSBjdXJyZW50IG1vZGVsLiBUbyBz b2x2ZSB0aGUgaXNzdWUgYXMgc2ltcGxlIGFzIHBvc3NpYmxlLCBpdCdzIHN1ZmZpY2llbnQgdG8g ZHVwbGljYXRlIHZwbi1wb2xpY3kgdW5kZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzcy4NCkluIHRoZXNl IGNhc2VzLCBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGNvbmNlcHR1YWwgZWxlbWVudCwgc3ViLXNp dGVzLCBpcyBub3QgcmVxdWlyZWQuIFRoaXMgbXVzdCBicmluZyBhIGNvbXBsZXhpdHksIGFuZCBz b21ldGltZXMgaGFyZCB0byBiZSB1bmRlcnN0b29kLCBkZXBlbmRpbmcgb24gb3BlcmF0b3IncyB1 c2VjYXNlLiANCkFsdGhvdWdoIHdlIHNob3VsZG4ndCBkaXNjdXNzIHRoZSBkZXZpY2UgbW9kZWxs aW5nLCB0aGUgZ3JhbnVsYXJpdHkgb2Ygc3ViLXNpdGVzIGNvcnJlc3BvbmRzIHRvIGEgVlJGJ3Mg b25lIGZyb20gdGhlIHZpZXdwb2ludCBvZiB2cG4tcG9saWN5LiBJbiB0aGlzIGNhc2UsIG5vYm9k eSBpbnR1aXRpdmVseSBpbWFnaW5lcyAoc3ViLSlzaXRlcyBmcm9tIFZSRiwgYmVjYXVzZSBpdCdz IGNvbW1vbmx5IGluIGEgc2luZ2xlIHBoeXNpY2FsIGJveC4NCg0KRllJLCBvdXIgY29tbWVyY2lh bCBzZXJ2aWNlIGhvbmVzdGx5IGhhcyBhIHNpbWlsYXIgZWxlbWVudCBhcyBzdWItc2l0ZXMsIGNv cnJlc3BvbmRpbmcgdG8gdmxhbiwgYnV0IHdlIHN0aWxsIGFsbG93cyBtdWx0aXBsZSB2cG5zIGFu ZCBiZ3AgcGVlcnMsIGVhY2ggZGlmZmVyZW50IHZwbiBhY2Nlc3MgcGVyIHBlZXIsIHdpdGhpbiBh IHNpbmdsZSB2bGFuLg0KDQpBbGwgdGhlIGJlc3QsDQpLZW5pY2hpDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2Ygc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20NClNlbnQ6IEZyaWRheSwg SmFudWFyeSAxNSwgMjAxNiAxMTozMSBQTQ0KVG86IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFtM M3NtXSBNb2RlbGluZyBhIHNpdGUgd2l0aCBtdWx0aXBsZSBzdWJzaXRlcw0KDQpbQ3JlYXRpbmcg YW5vdGhlciB0b3BpYyBmb3IgYmV0dGVyIGZvbGxvd3VwXQ0KDQogDQoNClRvZGF5IHRoZSBtb2Rl bCBoYXMgdGhlIGFiaWxpdHkgdG8gY3JlYXRlIHNpdGVzLCBhIHNpdGUgY2FuIGJlIG11bHRpaG9t ZWQgdG8gdGhlIG5ldHdvcmsgdGhhbmtzIHRvIHRoZSBzaXRlLW5ldHdvcmstYWNjZXNzIHN1Yi10 cmVlLg0KDQogDQoNCk5vdyB0aGUgcXVlc3Rpb24gaXMgaG93IHRvIHdlIG1vZGVsIHN1Y2ggc2Nl bmFyaW9zIDoNCg0KIA0KDQphKSAgICAgICJTVUJWUE4gY2FzZSIgOiBTaW5nbGUgInBoeXNpY2Fs IiBhY2Nlc3MgYmV0d2VlbiBTUCBhbmQgY3VzdG9tZXIsDQpidXQgbXVsdGlwbGUgc3ViLWFjY2Vz c2VzIG9uIHRvcCAoVkxBTiwgUFBQIHNlc3Npb25zLCBvciB3aGF0ZXZlciAuKSwgZWFjaCBvbmUg cG9pbnRpbmcgdG8gYSBzcGVjaWZpYyBWUE4uIEl0IGlzIGV4cGVjdGVkIGZvciB0aGUgY3VzdG9t ZXIgdG8gZW5zdXJlIGZsb3cgc2VwYXJhdGlvbiAoVlJGIGxpdGUsIFZMQU5zIC4pLiBJdCdzIHR5 cGljYWxseSBhIGJpZyBjb21wYW55IHdpdGggYSBIdWIgc2l0ZSB1c2VkIHdoZXJlIGFmZmlsaWF0 ZXMgaGF2ZSBkZWRpY2F0ZWQgcmVzb3VyY2VzIGluIHRoZSBIdWIgc2l0ZSwgYW5kIGFmZmlsaWF0 ZXMgbXVzdCBub3QgdGFsayB0byBlYWNoIG90aGVyIG9yIGV2ZW4gc2hhcmUgcmVzb3VyY2VzLiBO b3RlIHRoYXQgSSBwdXR0ZWQgInBoeXNpY2FsIiBiZXR3ZWVuIHF1b3RlcyBiZWNhdXNlIGl0IGNh biBiZSBhIG5lc3RlZCBsb2dpY2FsIGFjY2Vzc2VzIC4NCg0KIA0KDQogDQoNCmIpICAgICAgIklO VEVSLUFTIG9wdGlvbiBBIGxpa2UgIiBjYXNlIDogdGhpcyBpcyB0aGUgYmFjayB0byBiYWNrIFZS RiBjYXNlLA0KYXMgcHJldmlvdXNseSBzaW5nbGUgInBoeXNpY2FsIiBhY2Nlc3MgYW5kIG11bHRp cGxlIGxvZ2ljYWwgYWNjZXNzZXMgb24gdG9wIGVhY2ggb25lIHBvaW50aW5nIHRvIGEgc2VwYXJh dGUgVlBOLiBJIHB1dHRlZCBpbnRlckFTLCBidXQgdGhpcyBjYW4gYmUgImludHJhLUFTIiB3aXRo IGlCR1AgYmFjayB0byBiYWNrIFZSRnMgYWxzbyAoaW50ZXJuYWwgREMgZm9yIGV4YW1wbGUpDQoN CiANCg0KYykgICAgICAgV2hhdCBhYm91dCBvcHRpb24gQiA/IERvIHdlIGNvbnNpZGVyIG9wdGlv biBCIGFzIGEgc2VydmljZSA/IEkNCndvdWxkIG5vdCBiZSBpbiBmYXZvciBvZiB0aGF0LiBPcHRp b24gQiBzZXR1cHMgYXJlIHJlYWxseSBwYXJ0aWN1bGFyIGluIHRlcm0gb2YgZGVzaWduLCBzZWN1 cml0eSAuICBTbyBJIHdvdWxkIGxpa2UgdG8gaGF2ZSBvcHRpb24gQiBvdXQgb2Ygc2NvcGUuDQoN CiANCg0KIA0KDQpFdmVuIGlmIGEpIGFuZCBiKSBhcmUgc2VwYXJhdGVkIHVzZSBjYXNlcyBmcm9t IGEgc2VydmljZSBwb2ludCBvZiB2aWV3LCB0aGVzZSBhcmUgc2ltaWxhciBpbiB0ZXJtIG9mIG1v ZGVsaW5nLg0KDQogDQoNClRvZGF5IHdlIGNhbiBtb2RlbCBpdCBoYXMgYSBjb2xsZWN0aW9uIG9m IHNlcGFyYXRlZCBzaXRlcyB3aXRob3V0IGFueSByZWxhdGlvbnNoaXAgYmV0d2VlbiBlYWNoIG90 aGVyLiBUaGUgb3RoZXIgcG9pbnQgaXMgdGhhdCB3ZSBjYW5ub3QgZXhwcmVzcyBhbnkgIHByb3Bl cnR5IG9mIHRoZSAicGh5c2ljYWwiIGF0dGFjaG1lbnQgYnV0IHRoZXJlIG1heSBmZXcgKGVuY3J5 cHRpb24gPykuDQpXZSBjYW4ga2VlcCB0aGUgbW9kZWwgYXMgaXQgaXMgd2l0aCB0aGlzIGxpbWl0 YXRpb24gb3Igd2UgY2FuIGNyZWF0ZSBzaXRlIGFuZCBzdWItc2l0ZSBoaWVyYXJjaHkgd2hpY2gg YXMgSSBhbHJlYWR5IHNhaWQgbWF5IGNvbXBsZXhpZnkgdGhlIHJlYWRpbmcgYW5kIHVzYWJpbGl0 eSAoSU1PKS4NCg0KSXQgbWF5IGxvb2sgbGlrZSB0aGlzIDoNCg0KIA0KDQqhpCAgICAgICAgIFNp dGVzDQoNCm8gICBTaXRlLW9ubHktcGFyYW1ldGVycyA6DQoNCqHsICBMb2NhdGlvbg0KDQqh7CAg RGl2ZXJzaXR5DQoNCqHsICBtYW5hZ2VtZW50DQoNCqHsICBTZWN1cml0eQ0KDQpvICAgU3BlY2lm aWMtcGFyYW1ldGVycyA6IDwtIHRvIGJlIHVzZWQgb25seSBpZiB0aGVyZSBpcyBubyBzdWJzaXRl Lg0KDQqh7CAgVnBuLXBvbGljeQ0KDQqh7CAgU2VydmljZXMNCg0KoewgIFJvdXRpbmctcHJvdG9j b2xzDQoNCqHsICBTaXRlLW5ldHdvcmstYWNjZXNzZXMNCg0KoaQgICAgICAgICAuLg0KDQpvICAg U3ViLXNpdGVzIDogPC0gdG8gYmUgdXNlZCBpbiBjYXNlIG9mIHN1YiBzaXRlcyBwcmVzZW50DQoN CqHsICBTcGVjaWZpYy1wYXJhbWV0ZXJzIDoNCg0KoaQgICAgICAgICBWcG4tcG9saWN5DQoNCqGk ICAgICAgICAgU2VydmljZXMNCg0KoaQgICAgICAgICBSb3V0aW5nLXByb3RvY29scw0KDQqhpCAg ICAgICAgIFNpdGUtbmV0d29yay1hY2Nlc3Nlcw0KDQpvICAgLg0KDQogDQoNCkknbSBhbHNvIHdv bmRlcmluZyBpZiBiZWFyZXIgcGFyYW1ldGVycyBtdXN0IGFsc28gYmUgdGFrZW4gb3V0IGluIHRo aXMgY2FzZSBhbmQgcHV0dGVkIGluIHRoZSBzaXRlLW9ubHktcGFyYW1ldGVycy4gDQoNClRoZSBo aWVyYXJjaHkgYmVjb21lcyByZWFsbHkgY29tcGxleCBoZXJlIGFuZCBJIHdvdWxkIGxpa2UgdG8g a2VlcCBpdCBhcyBzaW1wbGUgYXMgcG9zc2libGUuDQoNCiANCg0KIA0KDQpXb3VsZCBiZSBnb29k IHRvIGhhdmUgbXVsdGlwbGUgZmVlZGJhY2tzIGZyb20gdGhlIFdHIHRvIHNlZSB3aGVyZSB0aGUg Y29uc2Vuc3VzIGlzLg0KDQogDQoNCiANCg0KT3JhbmdlIGxvZ28gPGh0dHA6Ly93d3cub3Jhbmdl LmNvbS8+IA0KDQogDQoNClN0ZXBoYW5lIExpdGtvd3NraQ0KTmV0d29yayBBcmNoaXRlY3QNCk9y YW5nZS9TQ0UvRVFVQU5UL09JTklTL05FVA0KDQpPcmFuZ2UgRXhwZXJ0IEZ1dHVyZSBOZXR3b3Jr cw0KDQpwaG9uZTogKzMzIDIgMjMgMjggNDkgODMNCjxodHRwczovL21vbnNpLnNzby5mcmFuY2V0 ZWxlY29tLmZyL2luZGV4LmFzcD90YXJnZXQ9aHR0cCUzQSUyRiUyRmNsaWN2b2ljZS4NCnNzby5m cmFuY2V0ZWxlY29tLmZyJTJGQ2xpY3ZvaWNlVjIlMkZUb29sQmFyLmRvJTNGYWN0aW9uJTNEZGVm YXVsdCUyNnJvb3RzZXINCnZpY2UlM0RTSUdOQVRVUkUlMjZ0byUzRCszMyUyMDIlMjAyMyUyMDI4 JTIwNDklMjA4MyUyMD4NCm1vYmlsZTogKzMzIDYgMzcgODYgOTcgNTINCjxodHRwczovL21vbnNp LnNzby5mcmFuY2V0ZWxlY29tLmZyL2luZGV4LmFzcD90YXJnZXQ9aHR0cCUzQSUyRiUyRmNsaWN2 b2ljZS4NCnNzby5mcmFuY2V0ZWxlY29tLmZyJTJGQ2xpY3ZvaWNlVjIlMkZUb29sQmFyLmRvJTNG YWN0aW9uJTNEZGVmYXVsdCUyNnJvb3RzZXINCnZpY2UlM0RTSUdOQVRVUkUlMjZ0byUzRCszMyUy MDYlMjAzNyUyMDg2JTIwOTclMjA1MiUyMD4NCnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29t IDxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+ICANCg0KIA0KDQogDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91 Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTDNz bSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbDNzbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KTDNzbSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KTDNzbSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkwzc20gbWFpbGluZyBsaXN0 DQpMM3NtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wz c20NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkwz c20gbWFpbGluZyBsaXN0DQpMM3NtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2wzc20NCg== From nobody Wed Feb 24 23:31:00 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18EA1A00E6 for ; Wed, 24 Feb 2016 23:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.048 X-Spam-Level: *** X-Spam-Status: No, score=3.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=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 2PCr0tp2fXKS for ; Wed, 24 Feb 2016 23:30:53 -0800 (PST) Received: from post-send.kddi.com (athena4.kddi.com [27.90.165.197]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6981A1B40 for ; Wed, 24 Feb 2016 23:30:52 -0800 (PST) Received: from LTMC2121.kddi.com (LTMC2121.kddi.com [10.206.0.61]) by post-send.kddi.com (KDDI Mail) with ESMTP id 0B1ED12013F; Thu, 25 Feb 2016 16:30:52 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2121.kddi.com with ESMTP; Thu, 25 Feb 2016 16:30:51 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id CFF4C4C005A; Thu, 25 Feb 2016 16:30:51 +0900 (JST) Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id C4D454C0058; Thu, 25 Feb 2016 16:30:51 +0900 (JST) Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1P7UpoW020779; Thu, 25 Feb 2016 16:30:51 +0900 Received: from LTMC2152.kddi.com.mid_32256302 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1P7Ko7o009412; Thu, 25 Feb 2016 16:20:50 +0900 X-SA-MID: 32256302 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Thu, 25 Feb 2016 16:20:49 +0900 From: "Ogaki, Kenichi" To: "'Aijun Wang'" <13301168517@189.cn>, , References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> <004101d16e97$e0692800$a13b7800$@kddi.com> <002d01d16e9f$88e66130$9ab32390$@cn> <006701d16ec0$1063fee0$312bfca0$@kddi.com> <004301d16ec8$270d9090$7528b1b0$@cn> <008401d16ede$20cee4c0$626cae40$@kddi.com> <004201d16f6f$22023cc0$6606b640$@cn> <015201d16f7c$3725b160$a5711420$@kddi.com> <008001d16f80$782b3690$6881a3b0$@cn> <018e01d16f88$3194dd50$94be97f0$@kddi.com> <009101d16f97$f8903440$e9b09cc0$@cn> In-Reply-To: <009101d16f97$f8903440$e9b09cc0$@cn> Date: Thu, 25 Feb 2016 16:20:50 +0900 Message-ID: <002f01d16f9d$0db35460$2919fd20$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+JsdlYZ7cvi/Fz8JTONaqj4LvoQKs2aO/AYjUCCUDWny42AHbJwT5AVTH19oBa6ZKmwJ6yFzNARuYlCYCFgz06wC+ia0/AXZZ+aGdQn32MA== Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 07:30:59 -0000 Hi Aijun, >1. When we add one new site into one already existing vpn, we need only = add one site item within this vpn, because the item sites is one list.=20 >This is very easy via the RESTCONF api. No other contents within this = vpn will be touched. For human being, this seems trivial. But, from a system automation viewpoint, the cost to access two = different top-level containers with restconf is not ignorable, because = restconf client must access two different URIs by at least two = transactions. >2. If you propose the Yang structure as that described in = https://mailarchive.ietf.org/arch/msg/l3sm/6zMiZSlcijda0ts_6NONdmwP3-E, = while not=20 >keep it consistence with the configuration part? You mean this cannot solve the problem? These state are not configurable and should be automatically derived = from the configuration of the sites in the current model.=20 Am I missing something? Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 3:44 PM To: 'Ogaki, Kenichi'; 'Aijun Wang'; stephane.litkowski@orange.com; = l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: 1. When we add one new site into one already existing vpn, we need only = add one site item within this vpn, because the item sites is one list. = This is very easy via the RESTCONF api. No other contents within this = vpn will be touched. 2. If you propose the Yang structure as that described in = https://mailarchive.ietf.org/arch/msg/l3sm/6zMiZSlcijda0ts_6NONdmwP3-E, = while not keep it consistence with the configuration part? Best Regards. -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Thursday, February 25, 2016 12:52 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >[Aijun Wang]: Within current Yang model, the customer need still to=20 >configure both sites and vpn-svc. If we use the site template, some = parameters that keep unchanged need not be input by customer. I'm saying the case just adding a new site to already existing vpn. Does = this require to configure the vpn?=20 >[Aijun Wang]: If the customer does not input these information, how can = >you get it from "op-state"? The operation state should consider only = the real time information that gathered from the underlying network = dynamically. In my understanding, it's not only for real time information. I mean the = following one. https://mailarchive.ietf.org/arch/msg/l3sm/6zMiZSlcijda0ts_6NONdmwP3-E Thanks, Kenichi -----Original Message----- From: Aijun Wang [mailto:13301168517@189.cn] Sent: Thursday, February 25, 2016 12:56 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Please see the comments inline, wish we can reach an agreement before = the interim meeting. :) -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Thursday, February 25, 2016 11:26 AM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, If we configure the relationship between vpn-svc and sites as follows, = we should remove corresponding vpn-policy under sites to avoid the = inconsistency. [Aijun Wang] Yes, we should redefine the vpn-policy as = site-prefix-policy, which defines only what prefix will be advertised by = this site, not the relationship among different sites. In this case, when we create new sites, we must configure both sites and = vpn-svc, and this bothers our customers. But, the current model structure only have to configure sites. Then, I = prefer the current one. [Aijun Wang]: Within current Yang model, the customer need still to = configure both sites and vpn-svc. If we use the site template, some = parameters that keep unchanged need not be input by customer. I don't object the sites list defined under vpn-svc as a *op-state*. [Aijun Wang]: If the customer does not input these information, how can = you get it from "op-state"? The operation state should consider only = the real time information that gathered from the underlying network = dynamically. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 10:52 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Based on our discussion, do you think the following proposal are = acceptable? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } =20 list sites{ leaf site-id leaf site-role leafref path "/l3vpn-svc/site-templates/site-template-id" = =20 } } list site-templates{ ...=20 } ... } -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Wednesday, February 24, 2016 4:34 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >Within the current Yang model, it is not loose coupled for the vpn and=20 >sites. Every site is associated with at least one vpn-policy entry. I wanted to mean by loose coupling that vpn and site should be = structurally at the same level. This means that a kind of graph = structure is better than a hierarchical structure. In a VPN service, it=E2=80=99s natural that a site must belong to at = least one vpn. >The reason that I prefer the "vpn-->site" structure to "site-->vpn"=20 >structure is that the majority of containers within lists "sites" are=20 >vpn-related, as you also confirmed this. >From the configuration viewpoint in the current model, the link = information between vpn and site can be configurable only in sites. = That's vpn-policy. This is reasonable to avoid the inconsistency in the case that both can = be configurable.=20 This information, which site belongs to which vpn, may be able to be = moved under vpn-svc as a list, but I don't think the necessity. It may = be useful to define the op-state under vpn-svc as discussed in issue#6. I agreed with the principle what you wrote, but I didn't carefully = discuss each container should be under vpn-svc or site. IMO, if any container is placed inappropriately, we should just move it = to the appropriate place. It's different problem from the model = structure discussion. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 2:57 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Within the current Yang model, it is not loose coupled for the vpn and = sites. Every site is associated with at least one vpn-policy entry.=20 The reason that I prefer the "vpn-->site" structure to "site-->vpn" = structure is that the majority of containers within lists "sites" are = vpn-related, as you also confirmed this. Then it is not enough in = current Yang model to correlate only the "vpn-policy" container to = different vpn id. And on the other way, we can also use the site-template to lessen the = burden of the customer configuration, as that done in current Yang = model. -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 12:59 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. > >[KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. >For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. >Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. >In that sense, I basically prefer the current model. >[Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. >There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement? If a physical customer site connects to two different vpns in this case, = the customer must input or update the information about the (physical) = site duplicately per vpn-svc. This may cause misconfiguration and bother = our customers. Another concern is the inconsistency with accounting/charging model, = when an operator charges the fee for physical access, it becomes = inconsistent with the charging model. When we does a traffic accounting = not only for logical access per vpn, but also for physical access, we = must always take care of the existence of different vpn-svc with the = same physical access in order to trigger a polling traffic counter of = the interface on PE. I understand it depends on each operator's service definition, vpn = specific or site specific, as Stephane wrote. To accommodate these different requirements, I think the loose coupled = model between the components, vpn and site, seems better. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 10:06 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Please see the reply inline. Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network = Research and Operation Support Department -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 8:11 AM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, See comments inline, please. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 18, 2016 1:12 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Stephane and Ogaki: =20 I suggested we put the "extranet-vpn-policy" under the list "vpn-svc" = directly, not in the container "vpn-policy" that is now under the list = "sites" in current model.=20 [KO]Like this? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } ... } ... } [Aijun Wang]: Yes. This can solve the initial scenario that proposed by Kenichi at the = beginning of our discussion. When the orchestrator receives the = information defined in "extranet-vpn-policy", it can allocate new = route-target for the involved VPNs and set them in the configuration = stanza of each router. =20 For the relationship of list "vpn-svc" and list "sites", I still suggest = we put the list "site" under the "vpn-svc", the reason for doing this is = as below: 1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. [KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. In that sense, I basically prefer the current model. [Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement?=20 2. The attributes of "sites", such as "maximum-routes", "security", = "service", "routing-protocols","site-netwok-accesses" etc. are all = service/site role related, that is to say, if the site role changed, all = of these attributed may be changed accordingly. [KO] I basically agree. The attributes tied to a whole vpn and globally = applied to all the sites under the vpn should be defined with the vpn = definition. 3.For container "vpn policy" that under list "sites" in current model, = there are two information defined, one is "filter" for prefix filtering, = another is "site-role". I suggest we split it, put the leaf "site-role" = under leaf "site-id" directly, and change the name of "vpn-policy" to = "site-prefix-policy".=20 =20 The final suggest structure of the L3VPN yang model will be look like = the bellow, I underline the changed positions from the current l3vpn = Yang Model =20 Container L3vpn-svc List vpn-svc Leaf vpn-id Leaf customer-name Leaf topology List extranet-vpn-policy Container cloud-access List multicast Leaf mpls List transport-contraints =20 List sites Leaf site-id Leaf site-role leaf apply-template ... ... ... ... Container managent Container site-prefix-policy Container maximum-routes Container security ... ... ... ... Site-network-access=20 =20 =20 Whether is it more reasonable?=20 =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute=20 Network Research and Operation Support Department =20 =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 18, 2016 9:08 AM To: l3sm@ietf.org Subject: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday = L3SM interim session =20 Hi Stephane and All, =20 As for issue #10 itself, the following solution can be acceptable for = us. =20 >One proposal could be to not call this VPN policy, but creating a >container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). =20 What model is in your mind? I can't see what ""extranet-vpn-policy" at = vpn" means. Like this? =20 ... 1 VPN1 VPN2 ... =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of stephane.litkowski@orange.com = =20 Sent: Monday, December 07, 2015 11:45 PM To: Ogaki, Kenichi; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi Kenichi, =20 Regarding your proposal of having a simple VPN policy in the vpn-svc = container, I do see an issue. One of the key point of the VPN policy is = to express the role of the site in the target VPN topology. If we do a vpn policy at VPN level, we cannot anymore describe site = roles in the target VPN which causes an issue. In an ideal world where all VPNs are any to any, the site role is always = the same and there is no issue, but let's think about someone trying to = use the vpn-policy (at vpn level) to connect to a Hub & Spoke VPN, how = do you deduce the roles of the sites ? =20 One proposal could be to not call this VPN policy, but creating a = container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). This means that the usage is really limited to "simple" = extranet-vpns and it does not replace nor compete with the VPN policy at = site level. =20 Could it be a good compromise ? =20 Stephane =20 =20 -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com = ] Sent: Saturday, December 05, 2015 06:23 To: LITKOWSKI Stephane SCE/OINIS; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear Stephane and All, =20 I don't say that sites *must* move under vpn-svc because I understand = stephane's use case. But we already have vpn-svc and some parameters under this are globally = applied to all the sites even in the current model. =20 It depends on operator's use case which is site-oriented or vpn-oriented = service. Our service is vpn-oriented, site has the native VPN. Then, I would just = like you to allow other global options to vpn-svc. =20 Thanks, Kenichi =20 -----Original Message----- From: stephane.litkowski@orange.com = = [mailto:stephane.litkowski@orange.com = ] Sent: Friday, December 04, 2015 8:17 PM To: Aijun Wang; 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi, =20 I'm against this proposal, as I do not want to create any dependency = between a particular VPN and a list of sites. A site can belong to multiple VPNs with any kind of topology, if we = attach the site to a single VPN, we come back to the notion of "native = VPN" we had at the beginning of the model which was hard to understand = and so was removed. =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Aijun Wang Sent: Friday, December 04, 2015 02:44 To: 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear all: =20 Can we put the list "sites" within the list "vpn-svc", and define the = general vpn policy for all sites that within the corresponding vpn = service instance? If doing so, some entries within the current list "sites" can also be = dragged out for general usual purposes, for example, "maximum-routes", = "security" etc. These parameters are often all same for every site = within one VPN service instance.=20 =20 If some sites have special requirements, we can achieve this by using = some special "site-vpn-policy" within the corresponding site definition. Is this more acceptable for customers? =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute Intelligent = Network Product Line =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Ogaki, Kenichi Sent: Friday, December 04, 2015 9:02 AM To: 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear All, =20 It was good having discussion. =20 As for issue#10, the objective and problem we discussed in the meeting = as follows. =20 The objective is to provide per-VPN extranet service which connects two = different VPNs (e.g. VPN1 and VPN2). It means that any sites in VPN1 can = access to any sites in VPN2. The problem is that the current model must update vpn-policy under all = the sites belong to these two VPNs in order to offer this service. = Especially when this model is used as a customer self-control API, it's = not good idea to require customers to update the information of all the = sites. (It's not abstracted way, a service model should provide what the = consumer wants, not how.) If a service or customer requires to control = per-site vpn-policy, that of current model should be used without = setting per-VPN vpn-polity. It depends on each operator's service. Stephane proposed to use apply-template, but it still cannot solve the = problem. When each VPN already has a large number of sites and want to = connect each other for the first time, both VPNs must update these sites = to apply apply-template on the current model. =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Qin Wu Sent: Friday, December 04, 2015 12:42 AM To: l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: [L3sm] L3SM interim meeting minutes on Thursday L3SM interim = session =20 Hi all: =20 =20 Below is the initial version of draft minutes for Thursday L3SM WG = interim session. =20 Thanks Dan to help take minutes. =20 Folks, please let us know if you have any correction. =20 =20 -Qin =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =20 L3SM Working Group Virtual Interim Meeting=20 =20 Thursday December 5th, 2015. 8am East Coast Time (New York) =20 =20 BLUE SHEET =20 =20 Name | Affiliation =20 ------------------------+----------------------------------------------- ------------------------+- =20 Adrian Farrel | Old Dog Consulting =20 Qin Wu | Huawei Technologies =20 Stephane Litkowski | Orange =20 Luis Tomotaki | Verizon =20 Daniel King | Old Dog Consulting =20 Susan Hares | Huawei Technologies =20 Scott Mansfield | Ericsson =20 Gu Rong | China Mobile=20 =20 Kenichi Ogaki | KDDI =20 Aijun Wang | China Telecom =20 Victor Santos | Ericsson =20 Ignas Bagdonas |=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 MINUTES =20 =20 * Meting logiistics = https://mailarchive.ietf.org/arch/msg/l3sm/SJub1aHVQGOQW6rWhthX0fB8Ac8 = = =20 =20 * Meeting materials = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/proceedings.html= = =20 =20 * Etherpad for minutes (this page) = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03 = =20 =20 * Jabber using l3sm@jabber.ietf.org =20 =20 * Blue sheet = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03-bluesheet = = =20 =20 =20 Agendaa =20 - Administrivia (Note Well, etc). a =20 - Introduction =20 - Open Issues for YANG Data Model for L3VPNservice delivery = (draft-ietf-l3sm-l3vpn-servicemodel) =20 o Open Issues discussion and resolution=E2=80=93 = http://trac.tools.ietf.org/wg/l3sm/trac/report/1 = =20 =20 =20 For a full list of issues and resolution proposals please see: = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/slides/slides-in= terim-2015-l3sm-1-2.pdf = =20 =20 =20 Issue#1: When customer-nat-address is used =20 Resolution #1: Leaf used when NAT is required to access cloud VPN and = customer wants to use its ownIP address. If provider provides the public = IP,no need to use the leaf =20 Status #1: Closed Pending I-D text review. =20 =20 Discussion on #1:=20 =20 =20 Aijun asks for more description in the YANG model itself =20 Stephane shows current model =20 Agreed OK =20 =20 Issue#2 : Identify l3vpn svc using id or name or both =20 Resolution #2: ID is a string, as per other properties in the model =20 Status #2: Closed =20 Discussion on #2:=20 =20 =20 Agreed OK =20 =20 Issue#3: M to N availability support =20 Resolution #3: Modeling sites using a list with a priority, so include = access list with a priority. =20 Status #3: =20 Discussion on #3:=20 =20 =20 Qin was asking that M to N availability is supported with access and = priority number.=20 =20 Stephane stated this is suppoted. This new proposal also supports = multiple sites, as a list. =20 Qin also asked if Group I-D was no longer needed, which it is not. Also = good solution supported by other operators. =20 Stephane asked if four priorities was enough, or if more were needed.=20 =20 =20 Re: Containers/Properties for Network Access Configuration - = Conclusions? =20 =20 o Location - Different site I-D? =20 o QoS Policy - Per network access link, or site information? Would QoS = (cost) be different per accesslink or site? Example of Primary and = Backup links given.=20 =20 o Bandwidth - Moved to access link group=20 =20 o Maximum Routes -=20 =20 Security, routing, and services are duplicated with inheritance =20 =20 =20 Issue#4: site-service-cloud access as grouping =20 Resolution #4 Already resilved as a separate grouping =20 Status #4: Closed =20 Discussion on #4:=20 =20 =20 Issue#5: Multicast support as raised by Eric Rosen =20 Resolution #5: : New "provider managed" property, and in Site Properties = "property-type" added =20 Status #5: Solution proposed.=20 =20 Discussion on #5:=20 =20 =20 Stephane will proviode new property proposals will be provided to Eric = for review.=20 =20 =20 Issue#6: Inventory operational state =20 Resolution #6: Include a new container for inventory state, or an RPC = call (sitting above the service orchestrator) to retrieve inventory = state.=20 =20 Status #6: Need to propose to the WG and agree solution. =20 Discussion on #6:=20 =20 =20 Luis asked would this info be collected from provision state? Stephane = suggested this would not be availible.=20 =20 Adrian observed that the code used to convert the model into a service = request may not utilise this inventory information capability. Sue = mentioned that others have mentioned by a vendor that it would be useful = to have the ability to configure inventory state. This should be = clarified by the operators.=20 =20 =20 Stephane to take proposals to list and ask anyone who is interested in = having the feature to suggest text. =20 =20 =20 Issue#7: Generic VAS - do we need to create a generic VAS container as = VAS are popular in L3VPNs? =20 Resolution #7: Separate from L3SM =20 Status #7: Closed =20 Discussion on #7:=20 =20 =20 Gu Rong highlighted Generic VAS model which was presented at IETF 94.=20 =20 =20 Issue#8: Who keeps site locationinformation? =20 Resolution #8: Text has been fixed =20 Status #8: Closed =20 Discussion on #8:=20 =20 =20 =20 Issue#9: Do we need to model transport constraints, such as: jitter, = disjoint, path diversity? =20 Resolution #9: Propose a "transport-constraint" group with = "constraint-type", "constraint-value" and "constraint-list" (composed of = type and values) =20 Status #9: Authors to propose the resolution in the I-D and provide to = the WG =20 Discussion on #9: =20 =20 =20 =20 Luis mentioned that they have multicast transport (multiple sites) and = bi-directional traffic applications (financial) that will require = transport constraints =20 =20 Duplicate transport constraints for unicast and multicast to give = options for separate configuration. =20 Keep single list entries for each src/dst pair even in the multicast = variant. =20 =20 DO we need to support multiple constraints or just have a single = composite (of multiple constraints), have the ability to specify a = constraint-list? =20 Aijun prfers list of constraints and meeting agrees this is OK =20 =20 What constraints to offer? =20 Latency =20 Path diversty =20 Site diversty =20 Jitter =20 Class of service was proposed but rejected =20 =20 Luis highlighted they have a current implementation that uses the = similar proposal. Luis also mentioned that site diversity might also be = required, would this be achievable =20 =20 =20 Issue#10: VPN "merging" =20 Resolution #10: =20 =20 Status #10: =20 Discussion on #10: =20 =20 =20 VPN is a per site property.=20 =20 - A site can belong tomultiple VPNs =20 - How to handle merging of two VPNs? =20 - Is this an issue the service model has to deal with? =20 =20 If VPN merging is required to be seamless, then this would be device = specific and not service model related. =20 =20 =20 "Merging" is a confusing term. The objective is NOT to merge VPN1 and = VPN2. =20 The objective is to provide an extranet so that some sites in VPN1 can = connect to some sites in VPN2 for some traffic. =20 This can be solved using a per-site property. =20 =20 Action: Need to update this issue to make it clear what function was = being discussed, also Stephane will send options to the working group- = list.=20 =20 We are specifically looking for people who offer extranet connection = between sites from different VPNs =20 =20 =3D=3D Other Issues =3D=3D =20 =20 =20 Modeling Customer Specific Info =20 - Create appropiate containers for Provider Edge and Customer Site = routers =20 - The current model contains routing parametres that refer to CE and PE = relationships =20 - General agreement is routing info should be split and current proposal = will be sent to the list for Kenichi, and working groups, review.=20 =20 =20 =3D=3D Conclusions =3D=3D =20 =20 - A number of resolutions have been agreed and will be updated in the = I-D =20 - Chairs would like to see revised I-D based on the agreed points =20 - Plan to have another interim call at the end of January (2016) =20 - Chairs to add new tracker items, including security for future = discussion.=20 =20 =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Wed Feb 24 23:33:53 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E3B1A0089 for ; Wed, 24 Feb 2016 23:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 PHDz60_UfJEW for ; Wed, 24 Feb 2016 23:33:47 -0800 (PST) Received: from post-send.kddi.com (athena4.kddi.com [27.90.165.197]) by ietfa.amsl.com (Postfix) with ESMTP id 080391A039E for ; Wed, 24 Feb 2016 23:33:47 -0800 (PST) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id 94FD712013F; Thu, 25 Feb 2016 16:33:46 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Thu, 25 Feb 2016 16:33:46 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 6652B4C005C; Thu, 25 Feb 2016 16:33:46 +0900 (JST) Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id 5B1774C0058; Thu, 25 Feb 2016 16:33:46 +0900 (JST) Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1P7Xj10023866; Thu, 25 Feb 2016 16:33:46 +0900 Received: from LTMC2152.kddi.com.mid_32256665 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1P7NfeR013017; Thu, 25 Feb 2016 16:23:42 +0900 X-SA-MID: 32256665 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Thu, 25 Feb 2016 16:23:41 +0900 From: "Ogaki, Kenichi" To: "'Aijun Wang'" <13301168517@189.cn>, "'Qin Wu'" , , References: <11137_1452868271_569902AF_11137_18933_1_9E32478DFA9976438E7A22F69B08FF921683F2D0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <009a01d1518a$dccd16e0$966744a0$@kddi.com> <28946_1453107612_569CA99C_28946_1310_1_9E32478DFA9976438E7A22F69B08FF921683F60F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <000001d15266$38428380$a8c78a80$@kddi.com> <002c01d16d15$fb50c390$f1f24ab0$@kddi.com> <018d01d16f88$2776fd80$7664f880$@kddi.com> <009301d16f9a$2fe4de30$8fae9a90$@cn> In-Reply-To: <009301d16f9a$2fe4de30$8fae9a90$@cn> Date: Thu, 25 Feb 2016 16:23:41 +0900 Message-ID: <003001d16f9d$74169280$5c43b780$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5Bq8eqk2F/jjoJjePPJmqqbPofQJPFi+8Aw+DAN8BzQ7zqQKVjWu7AxyabOkBlpm9KgJxHHHLnmX7m2A= Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Modeling a site with multiple subsites X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 07:33:52 -0000 Hi Aijun, No, I want to relate a specific site-network-access to a specific vpn. Even in a single site, two site-network-access should be relate to two = different vpns separately. Then, your proposal causes more complexity. https://mailarchive.ietf.org/arch/msg/l3sm/hJ7iJRp3vuB9Lp1INfW4NMj-bpI Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 4:00 PM To: 'Ogaki, Kenichi'; 'Qin Wu'; stephane.litkowski@orange.com; = l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi, Ogaki: Not only the site-network-access is related to specific vpn, almost most = of the site's parameters are all vpn related. I mentioned also this = issue in = https://mailarchive.ietf.org/arch/msg/l3sm/Hh4F8c8O2njayv3TWnZMmh5W3uY It seems we can solve such problem when we put the list site within the = list "vpn-svc". Best Regards. -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 25, 2016 12:51 PM To: 'Qin Wu'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi Qin, >Support subVPN case or multiple network accesses that is not for multihoming? Not for multihoming from a site to a single VPN(or under a single = vpn-policy). The current model can only differentiate vpn-policy per sites. But, = there are many use cases to require vpn-policy per site-network-access. You can find the current limitation and use cases on the exchanges in = this thread. >I believe this issue is separated from what we discussed earlier about extranet VPN policy. Yes, this is different issue. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu Sent: Thursday, February 25, 2016 12:57 PM To: Ogaki, Kenichi; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Kenichi: Can you clarify a little bit the objective of the following proposal? Support subVPN case or multiple network accesses that is not for = multihoming? I believe this issue is separated from what we discussed earlier about = extranet VPN policy. -Qin -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: L3sm [mailto:l3sm-bounces@ietf.org] =B4=FA=B1=ED = Ogaki, Kenichi =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C222=C8=D5 10:09 =CA=D5=BC=FE=C8=CB: stephane.litkowski@orange.com; l3sm@ietf.org =D6=F7=CC=E2: Re: [L3sm] Modeling a site with multiple subsites Hi Stephane and All, >>How to you differentiate multihoming from your subVPN case? they are=20 >>two different >things. >As I wrote, we just have to *duplicate* vpn-policy under=20 >site-network-access. When an operator's use case requires multiVPN,=20 >then vpn-policy should be under sites as the current model does. >When the other operator requires subVPN, vpn-policy should just be=20 >under site- network-access. It's sufficient to use these two cases exclusively. Here is a minimum modification proposal to the current model in order to = use these two cases exclusively. Only if a vpn-policy is not defined directly under sites, we can define = it under site-network-access. If something is grammatically wrong in terms of YANG and XPATH = expression, could anyone correct me? ... container site-network-accesses { list site-network-access { uses site-vpn-policy { refine vpn-policy { when "not(../../../vpn-policy)"; } } ... } ... } ... Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Tuesday, January 19, 2016 12:05 PM To: stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi Stephane, >We cannot use site-network-access which is used for multihoming only. Why do we have to use site-network-access only for multihoming? This is = intuitively mapped to a logical access as you wrote. >How to you differentiate multihoming from your subVPN case? they are=20 >two different things. As I wrote, we just have to *duplicate* vpn-policy under = site-network-access. When an operator's use case requires multiVPN, then = vpn-policy should be under sites as the current model does. When the other operator requires subVPN, vpn-policy should just be under = site-network-access. It's sufficient to use these two cases exclusively. >Could you provide more technical detail so I will be able to understand what exactly you are trying to achieve ? Our existing commercial service allows the *logically* following = diagram. PE1, PE2 and PE3 can be VRFs inside a single physical PE, or may be = physically separate PEs. Same as CEs. L2SW can be QinQ sub-interfaces on = a single physical PE depending on the above case. Then, we may map each element like this. sites: A customer premises connected via QinQ (stag 100) sub-sites: A customer premises' layer 2 segment separated by .1Q (ctag = 10 or 20), a ctag segment can include multiple logical accesses with bgp = peer per logical access. For example, PE1 has a bgp peer with CE1, and = PE2 has a different bgp peer with CE2. In this case, when VPN X only talks to LAN X, we need subVPN inside = sub-sites. But, we can deal with a sub-sites as a sites for the = simplicity to minimally extend the current model. Even so, we still need = vpn-policy per site-network-access. +-----------------------------+ +------------------------------+ | | | | | /---\ ctag 10 | | ctag 10 /---\ | | VPN A-+ PE1 +--------+ | | +--------+ CE1 +-LAN A | | \---/ | | | | \---/ | | | | | | | | /---\ctag 10+-+----+ |stag 100| +----+-+ctag 10/---\ | | VPN B-+ PE2 +------+ L2SW +-+--------+-+ L2SW +------+ CE2 +-LAN B | | \---/ +-+----+ | | +----+-+ \---/ | | | | | | | | /---\ctag 20 | | | | ctag 20 /---\ | | VPN C-+ PE3 +--------+ | | +--------+ CE3 +-LAN C | | \---/ | | \---/ | | | | | +-----------------------------+ +------------------------------+ Central Office Customer Premises All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Monday, January 18, 2016 6:00 PM To: Ogaki, Kenichi; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi, We cannot use site-network-access which is used for multihoming only. How to you differentiate multihoming from your subVPN case ? they are = two different things. So I'm completely against using site-network-accesses as a subVPN can be = also multihomed ... > FYI, our commercial service honestly has a similar element as=20 > sub-sites, corresponding to vlan, but we still allows multiple vpns and bgp peers, = each different vpn access per peer, within a single vlan. Could you provide more technical detail so I will be able to understand = what exactly you are trying to achieve ? Best Regards, Stephane -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Monday, January 18, 2016 01:55 To: LITKOWSKI Stephane SCE/OINIS; l3sm@ietf.org Subject: RE: [L3sm] Modeling a site with multiple subsites Hi Stephane, >Single "physical" access between SP and customer, but multiple=20 >sub-accesses on top (VLAN, PPP sessions, or whatever ...), each one pointing to a = specific VPN. As you wrote above in the scenario a) and b), vpn-policy only have to be = controlled per logical access, equivalent to the site-network-access in = the current model. To solve the issue as simple as possible, it's = sufficient to duplicate vpn-policy under site-network-access. In these cases, a completely different conceptual element, sub-sites, is = not required. This must bring a complexity, and sometimes hard to be = understood, depending on operator's usecase.=20 Although we shouldn't discuss the device modelling, the granularity of = sub-sites corresponds to a VRF's one from the viewpoint of vpn-policy. = In this case, nobody intuitively imagines (sub-)sites from VRF, because = it's commonly in a single physical box. FYI, our commercial service honestly has a similar element as sub-sites, = corresponding to vlan, but we still allows multiple vpns and bgp peers, = each different vpn access per peer, within a single vlan. All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Friday, January 15, 2016 11:31 PM To: l3sm@ietf.org Subject: [L3sm] Modeling a site with multiple subsites [Creating another topic for better followup] =20 Today the model has the ability to create sites, a site can be = multihomed to the network thanks to the site-network-access sub-tree. =20 Now the question is how to we model such scenarios : =20 a) "SUBVPN case" : Single "physical" access between SP and = customer, but multiple sub-accesses on top (VLAN, PPP sessions, or whatever .), = each one pointing to a specific VPN. It is expected for the customer to = ensure flow separation (VRF lite, VLANs .). It's typically a big company = with a Hub site used where affiliates have dedicated resources in the = Hub site, and affiliates must not talk to each other or even share = resources. Note that I putted "physical" between quotes because it can = be a nested logical accesses . =20 =20 b) "INTER-AS option A like " case : this is the back to back VRF = case, as previously single "physical" access and multiple logical accesses on = top each one pointing to a separate VPN. I putted interAS, but this can = be "intra-AS" with iBGP back to back VRFs also (internal DC for example) =20 c) What about option B ? Do we consider option B as a service ? I would not be in favor of that. Option B setups are really particular in = term of design, security . So I would like to have option B out of = scope. =20 =20 Even if a) and b) are separated use cases from a service point of view, = these are similar in term of modeling. =20 Today we can model it has a collection of separated sites without any = relationship between each other. The other point is that we cannot = express any property of the "physical" attachment but there may few = (encryption ?). We can keep the model as it is with this limitation or we can create = site and sub-site hierarchy which as I already said may complexify the = reading and usability (IMO). It may look like this : =20 =A1=A4 Sites o Site-only-parameters : =A1=EC Location =A1=EC Diversity =A1=EC management =A1=EC Security o Specific-parameters : <- to be used only if there is no subsite. =A1=EC Vpn-policy =A1=EC Services =A1=EC Routing-protocols =A1=EC Site-network-accesses =A1=A4 .. o Sub-sites : <- to be used in case of sub sites present =A1=EC Specific-parameters : =A1=A4 Vpn-policy =A1=A4 Services =A1=A4 Routing-protocols =A1=A4 Site-network-accesses o . =20 I'm also wondering if bearer parameters must also be taken out in this = case and putted in the site-only-parameters.=20 The hierarchy becomes really complex here and I would like to keep it as = simple as possible. =20 =20 Would be good to have multiple feedbacks from the WG to see where the = consensus is. =20 =20 Orange logo =20 =20 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 =20 =20 =20 _________________________________________________________________________= ___ _____________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Wed Feb 24 23:39:32 2016 Return-Path: <13301168517@189.cn> X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864431A1A54 for ; Wed, 24 Feb 2016 23:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.895 X-Spam-Level: ** X-Spam-Status: No, score=2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_LOCAL_DIGITS=0.001, FROM_LOCAL_HEX=0.006, HELO_IS_SMALL6=0.556, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 yNOvSy6ZbARW for ; Wed, 24 Feb 2016 23:39:27 -0800 (PST) Received: from 189.cn (mta.189.cn [121.14.53.140]) by ietfa.amsl.com (Postfix) with ESMTP id E71311A06FD for ; Wed, 24 Feb 2016 23:39:21 -0800 (PST) HMM_SOURCE_IP: 10.64.8.34:42726.789056793 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.77 (unknown [10.64.8.34]) by 189.cn (HERMES) with ESMTP id 5762E11C0D4; Thu, 25 Feb 2016 15:39:17 +0800 (CST) Received: from ctbriwangaij ([219.142.69.77]) by zm-as4(MEDUSA 0.0.0.0) with ESMTP id e162fdce-fe01-4141-8aaf-4e2b182588da for bill.wu@huawei.com; Thu Feb 25 15:39:20 2016 0/X-Total-Score: 0: X-FILTER-SCORE: to=<838a8d8d4f98966189968298868a4f84908e>, score=<1456385960AXXpXzApYGjT2EXXXXXzXX2EEREs2RMEs1QzEEEEEsEE> X-REAL-FROM: 13301168517@189.cn X-Receive-IP: 219.142.69.77 From: "Aijun Wang" <13301168517@189.cn> To: "'Qin Wu'" , "'Ogaki, Kenichi'" , , References: <11137_1452868271_569902AF_11137_18933_1_9E32478DFA9976438E7A22F69B08FF921683F2D0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <009a01d1518a$dccd16e0$966744a0$@kddi.com> <28946_1453107612_569CA99C_28946_1310_1_9E32478DFA9976438E7A22F69B08FF921683F60F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <000001d15266$38428380$a8c78a80$@kddi.com> <002c01d16d15$fb50c390$f1f24ab0$@kddi.com> <018d01d16f88$2776fd80$7664f880$@kddi.com> <009301d16f9a$2fe4de30$8fae9a90$@cn> In-Reply-To: Date: Thu, 25 Feb 2016 15:39:34 +0800 Message-ID: <009401d16f9f$ae1d8b30$0a58a190$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdFPnqCmtWfFPEtQT6m/5Yx5kcaoDABqSt8AABDyLYAAJeSogAar8U0AAKsvQfD//4regIAAJA2A//91RND//ub9gA== Content-Language: zh-cn Archived-At: Subject: Re: [L3sm] Modeling a site with multiple subsites X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 07:39:30 -0000 Hi,Qin: We can use a single service model to finish this task. The 3 different = VPN share the same model, but has different values for the nodes in the yang model. And currently, we are using the list "vpn-svc" to achieve this = for one specific customer in a single model. Best Regards. =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu Sent: Thursday, February 25, 2016 3:24 PM To: Aijun Wang; 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Interesting, one question I want to ask here when we model 5 sites = belonging to 3 different VPN, do we model them using a single service model or do = we create 3 service models with each modeling one VPN? In order words, do = we need to define a list of VPNs for the VPN service corresponding to a specific customer in a single model? -Qin -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Aijun Wang [mailto:13301168517@189.cn] =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C225=C8=D5 15:00 =CA=D5=BC=FE=C8=CB: 'Ogaki, Kenichi'; Qin Wu; = stephane.litkowski@orange.com; l3sm@ietf.org =D6=F7=CC=E2: RE: [L3sm] Modeling a site with multiple subsites Hi, Ogaki: Not only the site-network-access is related to specific vpn, almost most = of the site's parameters are all vpn related. I mentioned also this issue = in https://mailarchive.ietf.org/arch/msg/l3sm/Hh4F8c8O2njayv3TWnZMmh5W3uY It seems we can solve such problem when we put the list site within the = list "vpn-svc". Best Regards. -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 25, 2016 12:51 PM To: 'Qin Wu'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi Qin, >Support subVPN case or multiple network accesses that is not for multihoming? Not for multihoming from a site to a single VPN(or under a single vpn-policy). The current model can only differentiate vpn-policy per sites. But, = there are many use cases to require vpn-policy per site-network-access. You can find the current limitation and use cases on the exchanges in = this thread. >I believe this issue is separated from what we discussed earlier about extranet VPN policy. Yes, this is different issue. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu Sent: Thursday, February 25, 2016 12:57 PM To: Ogaki, Kenichi; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Kenichi: Can you clarify a little bit the objective of the following proposal? Support subVPN case or multiple network accesses that is not for multihoming? I believe this issue is separated from what we discussed earlier about extranet VPN policy. -Qin -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: L3sm [mailto:l3sm-bounces@ietf.org] =B4=FA=B1=ED = Ogaki, Kenichi =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C222=C8=D5 10:09 =CA=D5=BC=FE=C8=CB: stephane.litkowski@orange.com; l3sm@ietf.org =D6=F7=CC=E2: Re: [L3sm] Modeling a site with multiple subsites Hi Stephane and All, >>How to you differentiate multihoming from your subVPN case? they are=20 >>two different >things. >As I wrote, we just have to *duplicate* vpn-policy under=20 >site-network-access. When an operator's use case requires multiVPN,=20 >then vpn-policy should be under sites as the current model does. >When the other operator requires subVPN, vpn-policy should just be=20 >under site- network-access. It's sufficient to use these two cases exclusively. Here is a minimum modification proposal to the current model in order to = use these two cases exclusively. Only if a vpn-policy is not defined directly under sites, we can define = it under site-network-access. If something is grammatically wrong in terms of YANG and XPATH = expression, could anyone correct me? ... container site-network-accesses { list site-network-access { uses site-vpn-policy { refine vpn-policy { when "not(../../../vpn-policy)"; } } ... } ... } ... Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Tuesday, January 19, 2016 12:05 PM To: stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi Stephane, >We cannot use site-network-access which is used for multihoming only. Why do we have to use site-network-access only for multihoming? This is intuitively mapped to a logical access as you wrote. >How to you differentiate multihoming from your subVPN case? they are=20 >two different things. As I wrote, we just have to *duplicate* vpn-policy under site-network-access. When an operator's use case requires multiVPN, then vpn-policy should be under sites as the current model does. When the other operator requires subVPN, vpn-policy should just be under site-network-access. It's sufficient to use these two cases exclusively. >Could you provide more technical detail so I will be able to understand what exactly you are trying to achieve ? Our existing commercial service allows the *logically* following = diagram. PE1, PE2 and PE3 can be VRFs inside a single physical PE, or may be physically separate PEs. Same as CEs. L2SW can be QinQ sub-interfaces on = a single physical PE depending on the above case. Then, we may map each element like this. sites: A customer premises connected via QinQ (stag 100) sub-sites: A customer premises' layer 2 segment separated by .1Q (ctag = 10 or 20), a ctag segment can include multiple logical accesses with bgp peer = per logical access. For example, PE1 has a bgp peer with CE1, and PE2 has a different bgp peer with CE2. In this case, when VPN X only talks to LAN X, we need subVPN inside sub-sites. But, we can deal with a sub-sites as a sites for the = simplicity to minimally extend the current model. Even so, we still need vpn-policy = per site-network-access. +-----------------------------+ +------------------------------+ | | | | | /---\ ctag 10 | | ctag 10 /---\ | | VPN A-+ PE1 +--------+ | | +--------+ CE1 +-LAN A | | \---/ | | | | \---/ | | | | | | | | /---\ctag 10+-+----+ |stag 100| +----+-+ctag 10/---\ | | VPN B-+ PE2 +------+ L2SW +-+--------+-+ L2SW +------+ CE2 +-LAN B | | \---/ +-+----+ | | +----+-+ \---/ | | | | | | | | /---\ctag 20 | | | | ctag 20 /---\ | | VPN C-+ PE3 +--------+ | | +--------+ CE3 +-LAN C | | \---/ | | \---/ | | | | | +-----------------------------+ +------------------------------+ Central Office Customer Premises All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com Sent: Monday, January 18, 2016 6:00 PM To: Ogaki, Kenichi; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi, We cannot use site-network-access which is used for multihoming only. How to you differentiate multihoming from your subVPN case ? they are = two different things. So I'm completely against using site-network-accesses as a subVPN can be also multihomed ... > FYI, our commercial service honestly has a similar element as=20 > sub-sites, corresponding to vlan, but we still allows multiple vpns and bgp peers, = each different vpn access per peer, within a single vlan. Could you provide more technical detail so I will be able to understand = what exactly you are trying to achieve ? Best Regards, Stephane -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Monday, January 18, 2016 01:55 To: LITKOWSKI Stephane SCE/OINIS; l3sm@ietf.org Subject: RE: [L3sm] Modeling a site with multiple subsites Hi Stephane, >Single "physical" access between SP and customer, but multiple=20 >sub-accesses on top (VLAN, PPP sessions, or whatever ...), each one pointing to a specific VPN. As you wrote above in the scenario a) and b), vpn-policy only have to be controlled per logical access, equivalent to the site-network-access in = the current model. To solve the issue as simple as possible, it's sufficient = to duplicate vpn-policy under site-network-access. In these cases, a completely different conceptual element, sub-sites, is = not required. This must bring a complexity, and sometimes hard to be = understood, depending on operator's usecase.=20 Although we shouldn't discuss the device modelling, the granularity of sub-sites corresponds to a VRF's one from the viewpoint of vpn-policy. = In this case, nobody intuitively imagines (sub-)sites from VRF, because = it's commonly in a single physical box. FYI, our commercial service honestly has a similar element as sub-sites, corresponding to vlan, but we still allows multiple vpns and bgp peers, = each different vpn access per peer, within a single vlan. All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com Sent: Friday, January 15, 2016 11:31 PM To: l3sm@ietf.org Subject: [L3sm] Modeling a site with multiple subsites [Creating another topic for better followup] =20 Today the model has the ability to create sites, a site can be = multihomed to the network thanks to the site-network-access sub-tree. =20 Now the question is how to we model such scenarios : =20 a) "SUBVPN case" : Single "physical" access between SP and = customer, but multiple sub-accesses on top (VLAN, PPP sessions, or whatever .), = each one pointing to a specific VPN. It is expected for the customer to = ensure flow separation (VRF lite, VLANs .). It's typically a big company with a = Hub site used where affiliates have dedicated resources in the Hub site, and affiliates must not talk to each other or even share resources. Note = that I putted "physical" between quotes because it can be a nested logical = accesses . =20 =20 b) "INTER-AS option A like " case : this is the back to back VRF = case, as previously single "physical" access and multiple logical accesses on = top each one pointing to a separate VPN. I putted interAS, but this can be "intra-AS" with iBGP back to back VRFs also (internal DC for example) =20 c) What about option B ? Do we consider option B as a service ? I would not be in favor of that. Option B setups are really particular in = term of design, security . So I would like to have option B out of scope. =20 =20 Even if a) and b) are separated use cases from a service point of view, these are similar in term of modeling. =20 Today we can model it has a collection of separated sites without any relationship between each other. The other point is that we cannot = express any property of the "physical" attachment but there may few (encryption = ?). We can keep the model as it is with this limitation or we can create = site and sub-site hierarchy which as I already said may complexify the = reading and usability (IMO). It may look like this : =20 =A1=A4 Sites o Site-only-parameters : =A1=EC Location =A1=EC Diversity =A1=EC management =A1=EC Security o Specific-parameters : <- to be used only if there is no subsite. =A1=EC Vpn-policy =A1=EC Services =A1=EC Routing-protocols =A1=EC Site-network-accesses =A1=A4 .. o Sub-sites : <- to be used in case of sub sites present =A1=EC Specific-parameters : =A1=A4 Vpn-policy =A1=A4 Services =A1=A4 Routing-protocols =A1=A4 Site-network-accesses o . =20 I'm also wondering if bearer parameters must also be taken out in this = case and putted in the site-only-parameters.=20 The hierarchy becomes really complex here and I would like to keep it as simple as possible. =20 =20 Would be good to have multiple feedbacks from the WG to see where the consensus is. =20 =20 Orange logo =20 =20 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 =20 =20 =20 _________________________________________________________________________= ___ _____________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Wed Feb 24 23:42:16 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC351A1A42 for ; Wed, 24 Feb 2016 23:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 2sV9Uq_Jtsdv for ; Wed, 24 Feb 2016 23:42:11 -0800 (PST) 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 894551A007A for ; Wed, 24 Feb 2016 23:42:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJD27222; Thu, 25 Feb 2016 07:42:06 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 07:42:02 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 15:41:57 +0800 From: Qin Wu To: "Ogaki, Kenichi" , "l3sm@ietf.org" Thread-Topic: [L3sm] Notification support on L3SM Thread-Index: AdFHc4SIhFcUHomYSQSu07FkbZIQ5wmi+yMQABVGMwAAUo4wMA== Date: Thu, 25 Feb 2016 07:41:56 +0000 Message-ID: References: <016a01d14777$ce9ef7e0$6bdce7a0$@kddi.com> <004001d16e97$99f03b70$cdd0b250$@kddi.com> In-Reply-To: <004001d16e97$99f03b70$cdd0b250$@kddi.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.208] 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.0A090204.56CEB04F.0021, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1fadd3963ebe3246efa67507ae635055 Archived-At: Cc: Aijun Wang <13301168517@189.cn>, 'Aijun Wang' , "stephane.litkowski@orange.com" Subject: Re: [L3sm] Notification support on L3SM X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 07:42:15 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IE9nYWtpLCBLZW5pY2hpIFttYWlsdG86a2Utb29n YWtpQGtkZGkuY29tXSANCreiy83KsbzkOiAyMDE2xOoy1MIyNMjVIDg6MDkNCsrVvP7IyzogUWlu IFd1OyBsM3NtQGlldGYub3JnDQrW98ziOiBSRTogW0wzc21dIE5vdGlmaWNhdGlvbiBzdXBwb3J0 IG9uIEwzU00NCg0KSGkgUWluLA0KDQo+SW4gYWRkaXRpb24sIFlBTkcgMS4xIGNsZWFybHkgc3Bl Y2lmeSBsb2NhdGlvbiBvZiBub3RpZmljYXRpb24gaW4gdGhlIHNjaGVtYSB0cmVlLg0KPlNlZSBw YXJhZ3JhcGggMiwgc2VjdGlvbiA3LjE2IG9mIHJmYzYwMjBiaXMgIg0KPk5vdGlmaWNhdGlvbiBz aG91bGQgYmUgZGVmaW5lZCBhdCB0aGUgdG9wLWxldmVsIG9mIGEgbW9kdWxlLCBvciBjb25uZWN0 ZWQgdG8gYSBzcGVjaWZpYyBjb250YWluZXIgb3IgbGlzdCBkYXRhIG5vZGUgaW4gdGhlIHNjaGVt YSB0cmVlLiANCj4iDQo+SXQgY2FuIG5vdCBiZSByYW5kb21seSBkZWZpbmVkIGF0IGFueSBvdGhl ciBwbGFjZSBpbiB0aGUgc2NoZW1hIHRyZWUuIA0KDQpJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGUg bGltaXRhdGlvbiBvZiBub3RpZmljYXRpb24gc3RhdGVtZW50IHBsYWNlZCBvbmx5IGF0IHRvcC1s ZXZlbCBpbiBZQU5HIDEuMCBpcyByZWxpZXZlZCB0byBjb250YWluZXIgYW5kIGxpc3QgaW4gWUFO RyAxLjEuDQpBbiBleGFtcGxlIGlzIHNob3duIGluIGp1c3QgYmVmb3JlIHNlY3Rpb24gNy4xNyBv ZiByZmM2MDIwYmlzLg0KDQpbUWluXTogRXhhY3RseS4NCj5JIGFtIHdvbmRlcmluZyB3aGV0aGVy IHRoZXJlIGlzIGFueSBzcGVjaWZpYyBkYXRhIHlvdSB3YW50IHRvIGFkZCBpbiB0aGUgc2Vydmlj ZSBtb2RlbCBiZXNpZGVzICJhbnlkYXRhIGRhdGEiPw0KDQpUaGlzIGludGVuZHMgdGhhdCBob3cg dG8gdXNlIHRoZSBub3RpZmljYXRpb24gZGVwZW5kcyBvbiBlYWNoIG9wZXJhdG9yLg0KDQpbUWlu XTogQWdyZWUuDQo+SWYgdGhlcmUgaXMgbm8gc3BlY2lmaWMgZGF0YSB0aGF0IG5lZWRzIHRvIGJl IGFkZGVkLCBJIHRoaW5rIHdlIGtlZXAgDQo+c2VydmljZSBtb2RlbCBzaW1wbGUgYXMgYmFzZSBt b2RlbCwgZXh0ZW5kIGl0IGF0IGFueSB0aW1lIHRocm91Z2ggYXVnbWVudGF0aW9uIHdoZW4gc3Bl Y2lmaWMgZGF0YSBpcyBuZWVkZWQuDQoNClNvLCBJIGRvbid0IHN0aWNrIHRvIGRlZmluZSB0aGUg bm90aWZpY2F0aW9uIGF0IHRoaXMgcGhhc2UsIHVubGVzcyBhIHN0cm9uZyByZXF1aXJlbWVudC4N CkF1Z21lbnRhdGlvbiBpcyBnb29kIGVub3VnaC4NCg0KW1Fpbl06IFNvdW5kcyBnb29kLCBJIHRo aW5rIGJvdGggbm90aWZpY2F0aW9uIGFuZCBvcGVyYXRpb25hbCBpbnZlbnRvcnkoaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9sM3NtLzZ6TWlaU2xjaWpkYTB0c182Tk9OZG13 UDMtRSkgDQpjYW4gYmUgdXNlZCB0byBtb2RlbCBzdGF0ZSBkYXRhLiBXZSBuZWVkIHRvIGdldCBj b25zZW5zdXMgYmVmb3JlIGltcGxlbWVudGluZyB0aGlzLiANClRoZSBhdXRob3IncyBwcm9wb3Nh bCBvbiBvcGVyYXRpb25hbCBpbnZlbnRvcnkgaXM6DQphLkFkZCB0aHJlZSBuZXcgdG9wIGNvbnRh aW5lciB2cG4tc3ZjLXN0YXRlIHNpdGVzLXN0YXRlIGFuZCBzaXRlLXRlbXBsYXRlcy1zdGF0ZXMg YW5kIA0KY29weSBhbGwgdGhlIHBhcmFtZXRlcnMgaW4gdGhyZWUgZXhpc3RpbmcgY29udGFpbmVy IHZwbi1zdmMsc2l0ZXMsIHNpdGUtdGVtcGxhdGVzIHRvIHRoZXNlIG5ldyB0b3AgY29udGFpbmVy DQpiLlRoZW4gRGVmaW5lIHNpdGUgbGlzdCB1bmRlciB2cG4tc3ZjLXN0YXRlIGNvbnRhaW5lciwg dGhlIHNpdGUgbGlzdCBkZXNjcmliZXMgc2l0ZS1pZCBhbmQgc2l0ZSByb2xlLg0KDQpGb3IgKGIp LCBpdCBpcyBxdWl0ZSB0byBzaW1pbGFyIHRvIHdoYXQgQWlqdW4gV2FuZyBwcm9wb3NlLiBUaGUg ZGlmZmVyZW5jZSBpcyBBaWp1biBwcm9wb3NlZCB0byBkZWZpbmUgc2l0ZSBsaXN0IHVuZGVyIHZw bi1zdmMgbGlzdCBpbiB0aGUgY3VycmVudCBtb2RlbC4NCg0KSSBiZWxpZXZlIHlvdSBzdXBwb3J0 IG9wZXJhdGlvbmFsIGludmVudG9yeSwgd2UgYWxzbyB3YW50IHRvIGhlYXINCndoYXQgb3RoZXIg dGhpbmsgYWJvdXQgdGhpcz8NCg0KVGhhbmtzLA0KS2VuaWNoaQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFFpbiBXdQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjMsIDIwMTYgMzoyMiBQ TQ0KVG86IE9nYWtpLCBLZW5pY2hpOyBsM3NtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0wzc21d IE5vdGlmaWNhdGlvbiBzdXBwb3J0IG9uIEwzU00NCg0KSGksIEtlbmljaGk6DQpOb3RpZmljYXRp b24gc3VwcG9ydCBpcyBub3QgYSBuZXcgZmVhdHVyZSBpbiBZQU5HIDEuMSBhbmQgaXQgaGFzIGFs cmVhZHkgYmVlbiBzdXBwb3J0ZWQgYnkgWUFORyAxLjAuDQpUaGUgZGlmZmVyZW5jZSBiZXR3ZWVu IFlBTkcgMS4xIGFuZCBZQU5HIDEuMCBmb3IgTm90aWZpY2F0aW9uIGlzIHRvIHJlbW92ZSB0aWUg d2l0aCBORVRDT05GLCBtYWtlIG5vdGlmaWNhdGlvbiBub3Qgb25seSBhcHBsaWVkIHRvIE5FVENP TkYgYnV0IGFsc28gUkVTVENPTkYgb3Igb3RoZXIgdHJhbnNwb3J0IHByb3RvY29scy4NCg0KSW4g YWRkaXRpb24sIFlBTkcgMS4xIGNsZWFybHkgc3BlY2lmeSBsb2NhdGlvbiBvZiBub3RpZmljYXRp b24gaW4gdGhlIHNjaGVtYSB0cmVlLg0KU2VlIHBhcmFncmFwaCAyLCBzZWN0aW9uIDcuMTYgb2Yg cmZjNjAyMGJpcyAiDQpOb3RpZmljYXRpb24gc2hvdWxkIGJlIGRlZmluZWQgYXQgdGhlIHRvcC1s ZXZlbCBvZiBhIG1vZHVsZSwgb3IgY29ubmVjdGVkIHRvIGEgc3BlY2lmaWMgY29udGFpbmVyIG9y IGxpc3QgZGF0YSBub2RlIGluIHRoZSBzY2hlbWEgdHJlZS4gDQoiDQpJdCBjYW4gbm90IGJlIHJh bmRvbWx5IGRlZmluZWQgYXQgYW55IG90aGVyIHBsYWNlIGluIHRoZSBzY2hlbWEgdHJlZS4gDQpJ IGFtIHdvbmRlcmluZyB3aGV0aGVyIHRoZXJlIGlzIGFueSBzcGVjaWZpYyBkYXRhIHlvdSB3YW50 IHRvIGFkZCBpbiB0aGUgc2VydmljZSBtb2RlbCBiZXNpZGVzICJhbnlkYXRhIGRhdGEiPw0KSWYg dGhlcmUgaXMgbm8gc3BlY2lmaWMgZGF0YSB0aGF0IG5lZWRzIHRvIGJlIGFkZGVkLCBJIHRoaW5r IHdlIGtlZXAgc2VydmljZSBtb2RlbCBzaW1wbGUgYXMgYmFzZSBtb2RlbCwgZXh0ZW5kIGl0IGF0 IGFueSB0aW1lIHRocm91Z2ggYXVnbWVudGF0aW9uIHdoZW4gc3BlY2lmaWMgZGF0YSBpcyBuZWVk ZWQuDQoNCi1RaW4NCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBMM3NtIFttYWlsdG86bDNz bS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIE9nYWtpLCBLZW5pY2hpDQq3osvNyrG85DogMjAxNsTq MdTCNcjVIDEzOjEzDQrK1bz+yMs6IGwzc21AaWV0Zi5vcmcNCtb3zOI6IFtMM3NtXSBOb3RpZmlj YXRpb24gc3VwcG9ydCBvbiBMM1NNDQoNCkRlYXIgQWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gYXNr IHlvdSBpZiBhIG5vdGlmaWNhdGlvbiBzdXBwb3J0IGlzIG5lY2Vzc2FyeSBvbiB0aGUgbW9kZWwu DQpJIGRvbid0IHdhbnQgdG8gc3RpY2sgdG8gdGhpcyBhdCB0aGlzIHBoYXNlLCBidXQgdGhlcmUg YXJlIHNvbWUgdXNlIGNhc2VzLg0KDQpPcGVyYXRvcnMgbXVzdCBzb21ldGltZXMgbm90aWZ5IHZh cmlvdXMgaW5mb3JtYXRpb24gdG8gY3VzdG9tZXJzIHVuZGVyIGVhY2ggU0xBIHdpdGggdGhlbS4N Ci1tYWludGVuYW5jZSBzY2hlZHVsZSAocGxhbm5lZCwgaW4gb3BlcmF0aW9uKSAtcHJvYWN0aXZl IHJlcG9ydCB3aGVuIGEgZmFpbHVyZSBvY2N1cnJlZCgsIGV2ZW4gaWYgdGhlIGN1c3RvbWVyIGlz IG5vdCBhd2FyZSkNCg0KWUFORzEuMSB3aWxsIGFsbG93IG5vdGlmaWNhdGlvbnMgdG8gYmUgdGll ZCB0byBkYXRhIG5vZGVzLg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bmV0bW9kLXJmYzYwMjBiaXMtMDkjc2VjdGlvbi03LjE2DQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvbDNzbS8zNWVPMUtYWVlCRWhRNVRYSTBpaldlNU5xajQNCi0tDQoq bm90aWZpY2F0aW9uDQpIb3cgYWJvdXQgZGVmaW5pbmcgbm90aWZpY2F0aW9uIG5vZGUgdW5kZXIg dnBuLXN2YyBhbmQgc2l0ZS1uZXR3b3JrLWFjY2Vzcz8NCldlIHNvbWV0aW1lcyBoYXZlIHRvIGFj dGl2ZWx5IGluZm9ybSBvdXIgY3VzdG9tZXJzIG9mIGEgZmFpbHVyZSBvciBzb21ldGhpbmcuDQpX aGF0IGtpbmQgb2YgdGhlIGluZm9ybWF0aW9uIGRlcGVuZHMgb24gZWFjaCBvcGVyYXRvciwgdGhl biBhbnlkYXRhIG9yIGFueXhtbCBzdWl0cyB0aGlzLg0KDQpbU0xJXSBOb3RpZmljYXRpb24gYXJl IG5vcm1hbGx5IG5vdCBwYXJ0IG9mIHRoZSB0cmVlLCB3ZSBjYW4gY3JlYXRlIHJwY3Mgb3Igbm90 aWZpY2F0aW9ucyBpZiBuZWNlc3NhcnkgdG8gcmV0cmlldmUgb3BlcmF0aW9uYWwgaW5mb3MuDQpD b3VsZCB5b3UgcmFpc2UgYSBzZXBhcmF0ZSB0aHJlYWQgdG8gZGlzY3VzcyB0aGUgbmVlZCBvZiBu b3RpZmljYXRpb25zID8NCg0KDQpleC4pDQpjb250YWluZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzc2Vz IHsNCiAgICBsaXN0IHNpdGUtbmV0d29yay1hY2Nlc3Mgew0KICAgICAgICBrZXkgc2l0ZS1uZXR3 b3JrLWFjY2Vzcy1pZDsNCiAgICAgICAgLi4uDQogICAgICAgIG5vdGlmaWNhdGlvbiBpbmZvIHsN CiAgICAgICAgICAgIGFueWRhdGEgZGF0YTsNCiAgICAgICAgfQ0KICAgICAgICAuLi4NCn0NCi0t DQoNCi0tDQpLZW5pY2hpIE9nYWtpDQpLRERJIENvcnAuIHwgSVAgTmV0d29yayBEZXB0Lg0KKzgx LSgwKTgwLTU5NDUtOTEzOCB8IHd3dy5rZGRpLmNvbQ0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkwzc20gbWFpbGluZyBsaXN0DQpMM3NtQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMM3NtIG1haWxpbmcg bGlzdA0KTDNzbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9sM3NtDQoNCg== From nobody Thu Feb 25 00:18:18 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B226B1A024C for ; Thu, 25 Feb 2016 00:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.656 X-Spam-Level: **** X-Spam-Status: No, score=4.656 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, WEIRD_PORT=0.001] autolearn=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 7QOkqKfkuE6C for ; Thu, 25 Feb 2016 00:18:11 -0800 (PST) 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 0BC0A1A0135 for ; Thu, 25 Feb 2016 00:18:11 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8308222C6AB; Thu, 25 Feb 2016 09:18:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 66E1435C04E; Thu, 25 Feb 2016 09:18:09 +0100 (CET) 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; Thu, 25 Feb 2016 09:18:09 +0100 From: To: Aijun Wang <13301168517@189.cn>, "'Ogaki, Kenichi'" , "l3sm@ietf.org" Thread-Topic: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session Thread-Index: AdFUzU8XUm4agADpQBu6GQYzpCj8XwVLtpZwASTVPIAAAejoAAAIIwiAAAIEoAAABX+QAAAkPvQAAA9jniA= Date: Thu, 25 Feb 2016 08:18:08 +0000 Message-ID: <12175_1456388289_56CEB8C1_12175_6085_1_9E32478DFA9976438E7A22F69B08FF92168CA7B1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> <004101d16e97$e0692800$a13b7800$@kddi.com> <002d01d16e9f$88e66130$9ab32390$@cn> <006701d16ec0$1063fee0$312bfca0$@kddi.com> <004301d16ec8$270d9090$7528b1b0$@cn> <008401d16ede$20cee4c0$626cae40$@kddi.com> <004201d16f6f$22023cc0$6606b640$@cn> In-Reply-To: <004201d16f6f$22023cc0$6606b640$@cn> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.25.73617 Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 08:18:16 -0000 SGksDQoNCkkgcGVyc29ubmFseSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlcyBvZiB5 b3VyIHByb3Bvc2FsLiBGb3IgbWUsIGFuZCBLZW5pY2hpIHBvaW50ZWQgaXQgYWxzbywgaXQgYnJp bmdzIG1vcmUgY29tcGxleGl0eSBhbmQgcmVxdWlyZW1lbnQgb2YgZHVwbGljYXRpbmcgbWFueSBj b25maWd1cmF0aW9uLg0KVG8gc2F5IGl0IGFnYWluLCBtdWx0aVZQTiBpcyByZWFsbHkgcmVhbGx5 IGNvbW1vbiBhbmQgd2UgaGF2ZSBzb21lIHNpdGVzIGJlbG9uZ2luZyB0byBtb3JlIHRoYW4gMTAg VlBOcyBhbmQgd2UgbmVlZCBhbiBlYXN5IHdheSB0byBhdHRhY2ggYSBzaXRlIHRvIGEgbmV3IFZQ Ti4NCg0KSSBkbyBub3Qgc2VlIGFueSBzaXRlIGF0dHJpYnV0ZSB3aGljaCBzaG91bGQgYmUgbW92 ZWQgdG8gVlBOLCBidXQgaWYgeW91IGZpbmQgb25lLCBwbGVhc2Ugc3RhdGUgaXQgY2xlYXJseSBh bmQgZXhwbGFpbiB3aHkgYmVjYXVzZSBpdCdzIG5vdCBjbGVhciBmb3Igbm93Lg0KDQpCZXN0IFJl Z2FyZHMsDQoNClN0ZXBoYW5lDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEFpanVuIFdhbmcgW21haWx0bzoxMzMwMTE2ODUxN0AxODkuY25dIA0KU2VudDogVGh1cnNkYXks IEZlYnJ1YXJ5IDI1LCAyMDE2IDAyOjUyDQpUbzogJ09nYWtpLCBLZW5pY2hpJzsgTElUS09XU0tJ IFN0ZXBoYW5lIFNDRS9PSU5JUzsgbDNzbUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtMM3NtXSBJ c3N1ZSAjMTAgUkU6IEwzU00gaW50ZXJpbSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNT TSBpbnRlcmltIHNlc3Npb24NCg0KSGksIE9nYWtpOg0KDQpCYXNlZCBvbiBvdXIgZGlzY3Vzc2lv biwgZG8geW91IHRoaW5rIHRoZSBmb2xsb3dpbmcgcHJvcG9zYWwgYXJlIGFjY2VwdGFibGU/DQoN CiAgICBjb250YWluZXIgbDN2cG4tc3ZjIHsNCiAgICAgICAgbGlzdCB2cG4tc3ZjIHsNCiAgICAg ICAgICAgIGtleSB2cG4taWQ7DQoNCiAgICAgICAgICAgIGxlYWYgdnBuLWlkIHsNCiAgICAgICAg ICAgICAgICDigKYNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIC4uLg0KICAgICAgICAgICAg bGlzdCBleHRyYW5ldC12cG4tcG9saWN5IHsNCiAgICAgICAgICAgICAgICBrZXkgdnBuLWlkOw0K ICAgICAgICAgICAgICAgIGxlYWYgdnBuLWlkIHsNCiAgICAgICAgICAgICAgICAgICAgdHlwZSBz dmMtaWQ7DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KICAgICAgICANCiAgICAg ICAgICAgIGxpc3Qgc2l0ZXN7DQogICAgICAgICAgICAgIGxlYWYgc2l0ZS1pZA0KICAgICAgICAg ICAgICBsZWFmIHNpdGUtcm9sZQ0KICAgICAgICAgICAgICBsZWFmcmVmIHBhdGggIi9sM3Zwbi1z dmMvc2l0ZS10ZW1wbGF0ZXMvc2l0ZS10ZW1wbGF0ZS1pZCIgICAgDQogICAgICAgICAgICB9DQog ICAgICAgIH0NCg0KICAgICAgICBsaXN0IHNpdGUtdGVtcGxhdGVzew0KICAgICAgICAuLi4gDQog ICAgICAgIH0NCiAgICAgICAgLi4uDQogICAgfQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE9nYWtpLCBLZW5pY2hpDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDQ6MzQg UE0NClRvOiAnQWlqdW4gV2FuZyc7IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBsM3Nt QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0wzc21dIElzc3VlICMxMCBSRTogTDNTTSBpbnRlcmlt IG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGludGVyaW0gc2Vzc2lvbg0KDQpIaSBB aWp1biwNCg0KPldpdGhpbiB0aGUgY3VycmVudCBZYW5nIG1vZGVsLCBpdCBpcyBub3QgbG9vc2Ug Y291cGxlZCBmb3IgdGhlIHZwbiBhbmQgDQo+c2l0ZXMuIEV2ZXJ5IHNpdGUgaXMgYXNzb2NpYXRl ZCB3aXRoIGF0IGxlYXN0IG9uZSB2cG4tcG9saWN5IGVudHJ5Lg0KDQpJIHdhbnRlZCB0byBtZWFu IGJ5IGxvb3NlIGNvdXBsaW5nIHRoYXQgdnBuIGFuZCBzaXRlIHNob3VsZCBiZSBzdHJ1Y3R1cmFs bHkgYXQgdGhlIHNhbWUgbGV2ZWwuIFRoaXMgbWVhbnMgdGhhdCBhIGtpbmQgb2YgZ3JhcGggc3Ry dWN0dXJlIGlzIGJldHRlciB0aGFuIGEgaGllcmFyY2hpY2FsIHN0cnVjdHVyZS4NCkluIGEgVlBO IHNlcnZpY2UsIGl04oCZcyBuYXR1cmFsIHRoYXQgYSBzaXRlIG11c3QgYmVsb25nIHRvIGF0IGxl YXN0IG9uZSB2cG4uDQoNCg0KPlRoZSByZWFzb24gdGhhdCBJIHByZWZlciB0aGUgInZwbi0tPnNp dGUiIHN0cnVjdHVyZSB0byAic2l0ZS0tPnZwbiIgDQo+c3RydWN0dXJlIGlzIHRoYXQgdGhlIG1h am9yaXR5IG9mIGNvbnRhaW5lcnMgd2l0aGluIGxpc3RzICJzaXRlcyIgYXJlIA0KPnZwbi1yZWxh dGVkLCBhcyB5b3UgYWxzbyBjb25maXJtZWQgdGhpcy4NCg0KPkZyb20gdGhlIGNvbmZpZ3VyYXRp b24gdmlld3BvaW50IGluIHRoZSBjdXJyZW50IG1vZGVsLCB0aGUgbGluayBpbmZvcm1hdGlvbiBi ZXR3ZWVuIHZwbiBhbmQgc2l0ZSBjYW4gYmUgY29uZmlndXJhYmxlIG9ubHkgaW4gc2l0ZXMuIFRo YXQncyB2cG4tcG9saWN5Lg0KVGhpcyBpcyByZWFzb25hYmxlIHRvIGF2b2lkIHRoZSBpbmNvbnNp c3RlbmN5IGluIHRoZSBjYXNlIHRoYXQgYm90aCBjYW4gYmUgY29uZmlndXJhYmxlLiANClRoaXMg aW5mb3JtYXRpb24sIHdoaWNoIHNpdGUgYmVsb25ncyB0byB3aGljaCB2cG4sIG1heSBiZSBhYmxl IHRvIGJlIG1vdmVkIHVuZGVyIHZwbi1zdmMgYXMgYSBsaXN0LCBidXQgSSBkb24ndCB0aGluayB0 aGUgbmVjZXNzaXR5LiBJdCBtYXkgYmUgdXNlZnVsIHRvIGRlZmluZSB0aGUgb3Atc3RhdGUgdW5k ZXIgdnBuLXN2YyBhcyBkaXNjdXNzZWQgaW4gaXNzdWUjNi4NCg0KSSBhZ3JlZWQgd2l0aCB0aGUg cHJpbmNpcGxlIHdoYXQgeW91IHdyb3RlLCBidXQgSSBkaWRuJ3QgY2FyZWZ1bGx5IGRpc2N1c3Mg ZWFjaCBjb250YWluZXIgc2hvdWxkIGJlIHVuZGVyIHZwbi1zdmMgb3Igc2l0ZS4NCklNTywgaWYg YW55IGNvbnRhaW5lciBpcyBwbGFjZWQgaW5hcHByb3ByaWF0ZWx5LCB3ZSBzaG91bGQganVzdCBt b3ZlIGl0IHRvIHRoZSBhcHByb3ByaWF0ZSBwbGFjZS4gSXQncyBkaWZmZXJlbnQgcHJvYmxlbSBm cm9tIHRoZSBtb2RlbCBzdHJ1Y3R1cmUgZGlzY3Vzc2lvbi4NCg0KDQpUaGFua3MsDQpLZW5pY2hp DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KU2VudDogV2VkbmVzZGF5 LCBGZWJydWFyeSAyNCwgMjAxNiAyOjU3IFBNDQpUbzogJ09nYWtpLCBLZW5pY2hpJzsgc3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTDNz bV0gSXNzdWUgIzEwIFJFOiBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9uIFRodXJzZGF5 IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCkhpLCBPZ2FraToNCg0KV2l0aGluIHRoZSBjdXJyZW50 IFlhbmcgbW9kZWwsIGl0IGlzIG5vdCBsb29zZSBjb3VwbGVkIGZvciB0aGUgdnBuIGFuZCBzaXRl cy4gRXZlcnkgc2l0ZSBpcyBhc3NvY2lhdGVkIHdpdGggYXQgbGVhc3Qgb25lIHZwbi1wb2xpY3kg ZW50cnkuIA0KVGhlIHJlYXNvbiB0aGF0IEkgcHJlZmVyIHRoZSAidnBuLS0+c2l0ZSIgc3RydWN0 dXJlIHRvICJzaXRlLS0+dnBuIiBzdHJ1Y3R1cmUgaXMgdGhhdCB0aGUgbWFqb3JpdHkgb2YgY29u dGFpbmVycyB3aXRoaW4gbGlzdHMgInNpdGVzIiBhcmUgdnBuLXJlbGF0ZWQsIGFzIHlvdSBhbHNv IGNvbmZpcm1lZCB0aGlzLiBUaGVuIGl0IGlzIG5vdCBlbm91Z2ggaW4gY3VycmVudCBZYW5nIG1v ZGVsIHRvIGNvcnJlbGF0ZSBvbmx5IHRoZSAidnBuLXBvbGljeSIgY29udGFpbmVyIHRvIGRpZmZl cmVudCB2cG4gaWQuDQpBbmQgb24gdGhlIG90aGVyIHdheSwgd2UgY2FuIGFsc28gdXNlIHRoZSBz aXRlLXRlbXBsYXRlIHRvIGxlc3NlbiB0aGUgYnVyZGVuIG9mIHRoZSBjdXN0b21lciBjb25maWd1 cmF0aW9uLCBhcyB0aGF0IGRvbmUgaW4gY3VycmVudCBZYW5nIG1vZGVsLg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT2dha2ksIEtlbmljaGkgW21haWx0bzprZS1vb2dha2lA a2RkaS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEyOjU5IFBNDQpU bzogJ0FpanVuIFdhbmcnOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBpZXRm Lm9yZw0KU3ViamVjdDogUkU6IFtMM3NtXSBJc3N1ZSAjMTAgUkU6IEwzU00gaW50ZXJpbSBtZWV0 aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KSGkgQWlqdW4s DQoNCj4xLiB0aGUgc2VydmljZSBtb2RlbCBtdXN0IGJlIHNlcnZpY2Ugb3JpZW50ZWQuIElmIG9u ZSBzaXRlIGJlbG9uZ3MgdG8gc2V2ZXJhbCB2cG5zLCB3ZSBzaG91bGQgYWNoaWV2ZSB0aGUgZ29h bCBieSBkZWZpbmluZyBzZXZlcmFsIHNlcnZpY2UgaW5zdGFuY2VzLg0KPg0KPltLT10gSSBjYW4n dCBhZ3JlZSB0aGlzLiBUaGUgY2FzZSB0aGF0IGEgc2l0ZSBiZWxvbmdzIHRvIG11bHRpcGxlIHZw bnMgaXMgYWxzbyBhIHZlcnkgY29tbW9uIHNlcnZpY2UgdXNlIGNhc2UsIHRoZW4gdGhlIHNlcnZp Y2UgbW9kZWwgbXVzdCBkZXNpZ24gdGhpcyBhcHByb3ByaWF0ZWx5Lg0KPkZvciBlYXN5IHVzZSBv ZiBhIHNlcnZpY2UgbW9kZWwgYW5kIHRvIGF2b2lkIHRoZSBtaXNjb25maWd1cmF0aW9uIGFuZCBp bmNvbnNpc3RlbmN5LCB3ZSBoYXZlIHRvIGV4Y2x1ZGUgZHVwbGljYXRlIGNvbmZpZ3VyYXRpb24g Zm9yIHRoZSBzYW1lIGluZm9ybWF0aW9uLCBkYXRhIG5vZGUgaW5zdGFuY2UsIGFzIG11Y2ggYXMg cG9zc2libGUuID5UaGVuLCBJIHByb3Bvc2VkIHRvIHJlbW92ZSByZXBldGl0aXZlIGRlZmluaXRp b25zIG9mIGEgdnBuIHdoaWNoIGNhbiBiZSBpbXBsaWNpdGx5IHVuaXF1ZWx5IGlkZW50aWZpZWQg aW4gYSBzYW1lIHRyYW5zYWN0aW9uLiBCdXQsIHRoYXQgZXZlbnR1YWxseSBjYW1lIG5vdCB0byBt YWtlIHNlbnNlIGZvciByZXN0Y29uZi4NCj5JbiB0aGF0IHNlbnNlLCBJIGJhc2ljYWxseSBwcmVm ZXIgdGhlIGN1cnJlbnQgbW9kZWwuDQo+W0FpanVuIFdhbmddOiBmb3Igc2l0ZXMgdGhhdCBiZWxv bmcgdG8gc2V2ZXJhbCB2cG5zLCBiZWNhdXNlIHdlIGRlZmluZSAidnBuLXN2YyIgYXMgbGlzdCwg dGhlbiBpdCBjYW4gaW5jbHVkZSBkaWZmZXJlbnQgaXRlbXMsIGVhY2ggdnBuLXN2YyBpdGVtIGNh biBkZWZpbmUgaXRzIG93biBzaXRlcyBjb3ZlcmFnZSBpbmZvcm1hdGlvbi4gPlRoZXJlIGlzIGFs c28gbm8gZHVwbGljYXRlIGNvbmZpZ3VyYXRpb24gZm9yIHRoaXMgc29sdXRpb24uIFdoYXQncyB0 aGUgcHJvYmxlbSB0aGVuIGZvciB0aGlzIGFycmFuZ2VtZW50Pw0KDQpJZiBhIHBoeXNpY2FsIGN1 c3RvbWVyIHNpdGUgY29ubmVjdHMgdG8gdHdvIGRpZmZlcmVudCB2cG5zIGluIHRoaXMgY2FzZSwg dGhlIGN1c3RvbWVyIG11c3QgaW5wdXQgb3IgdXBkYXRlIHRoZSBpbmZvcm1hdGlvbiBhYm91dCB0 aGUgKHBoeXNpY2FsKSBzaXRlIGR1cGxpY2F0ZWx5IHBlciB2cG4tc3ZjLiBUaGlzIG1heSBjYXVz ZSBtaXNjb25maWd1cmF0aW9uIGFuZCBib3RoZXIgb3VyIGN1c3RvbWVycy4NCkFub3RoZXIgY29u Y2VybiBpcyB0aGUgaW5jb25zaXN0ZW5jeSB3aXRoIGFjY291bnRpbmcvY2hhcmdpbmcgbW9kZWws IHdoZW4gYW4gb3BlcmF0b3IgY2hhcmdlcyB0aGUgZmVlIGZvciBwaHlzaWNhbCBhY2Nlc3MsIGl0 IGJlY29tZXMgaW5jb25zaXN0ZW50IHdpdGggdGhlIGNoYXJnaW5nIG1vZGVsLiBXaGVuIHdlIGRv ZXMgYSB0cmFmZmljIGFjY291bnRpbmcgbm90IG9ubHkgZm9yIGxvZ2ljYWwgYWNjZXNzIHBlciB2 cG4sIGJ1dCBhbHNvIGZvciBwaHlzaWNhbCBhY2Nlc3MsIHdlIG11c3QgYWx3YXlzIHRha2UgY2Fy ZSBvZiB0aGUgZXhpc3RlbmNlIG9mIGRpZmZlcmVudCB2cG4tc3ZjIHdpdGggdGhlIHNhbWUgcGh5 c2ljYWwgYWNjZXNzIGluIG9yZGVyIHRvIHRyaWdnZXIgYSBwb2xsaW5nIHRyYWZmaWMgY291bnRl ciBvZiB0aGUgaW50ZXJmYWNlIG9uIFBFLg0KDQpJIHVuZGVyc3RhbmQgaXQgZGVwZW5kcyBvbiBl YWNoIG9wZXJhdG9yJ3Mgc2VydmljZSBkZWZpbml0aW9uLCB2cG4gc3BlY2lmaWMgb3Igc2l0ZSBz cGVjaWZpYywgYXMgU3RlcGhhbmUgd3JvdGUuDQoNClRvIGFjY29tbW9kYXRlIHRoZXNlIGRpZmZl cmVudCByZXF1aXJlbWVudHMsIEkgdGhpbmsgdGhlIGxvb3NlIGNvdXBsZWQgbW9kZWwgYmV0d2Vl biB0aGUgY29tcG9uZW50cywgdnBuIGFuZCBzaXRlLCBzZWVtcyBiZXR0ZXIuDQoNClRoYW5rcywN CktlbmljaGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEwzc20gW21haWx0 bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBaWp1biBXYW5nDQpTZW50OiBX ZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjA2IEFNDQpUbzogJ09nYWtpLCBLZW5pY2hp Jzsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbTDNzbV0gSXNzdWUgIzEwIFJFOiBMM1NNIGludGVyaW0gbWVldGluZyBtaW51dGVzIG9u IFRodXJzZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCkhpLCBPZ2FraToNCg0KUGxlYXNlIHNl ZSB0aGUgcmVwbHkgaW5saW5lLg0KDQoNCkJlc3QgUmVnYXJkcy4NCg0KQWlqdW4gV2FuZw0KDQpD aGluYSBUZWxlY29tIENvcnBvcmF0aW9uIExpbWl0ZWQgQmVpamluZyBSZXNlYXJjaCBJbnN0aXR1 dGUgTmV0d29yayBSZXNlYXJjaCBhbmQgT3BlcmF0aW9uIFN1cHBvcnQgRGVwYXJ0bWVudA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT2dha2ksIEtlbmljaGkgW21haWx0bzpr ZS1vb2dha2lAa2RkaS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDg6 MTEgQU0NClRvOiAnQWlqdW4gV2FuZyc7IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBs M3NtQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0wzc21dIElzc3VlICMxMCBSRTogTDNTTSBpbnRl cmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGludGVyaW0gc2Vzc2lvbg0KDQpI aSBBaWp1biwNCg0KU2VlIGNvbW1lbnRzIGlubGluZSwgcGxlYXNlLg0KDQpUaGFua3MsDQpLZW5p Y2hpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMM3NtIFttYWlsdG86bDNz bS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KU2VudDogVGh1cnNk YXksIEZlYnJ1YXJ5IDE4LCAyMDE2IDE6MTIgUE0NClRvOiAnT2dha2ksIEtlbmljaGknOyBzdGVw aGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtM M3NtXSBJc3N1ZSAjMTAgUkU6IEwzU00gaW50ZXJpbSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNk YXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KSGksIFN0ZXBoYW5lIGFuZCBPZ2FraToNCg0KIA0K DQpJIHN1Z2dlc3RlZCB3ZSBwdXQgdGhlICJleHRyYW5ldC12cG4tcG9saWN5IiB1bmRlciB0aGUg bGlzdCAidnBuLXN2YyIgZGlyZWN0bHksIG5vdCBpbiB0aGUgY29udGFpbmVyICJ2cG4tcG9saWN5 IiB0aGF0IGlzIG5vdyB1bmRlciB0aGUgbGlzdCAic2l0ZXMiIGluIGN1cnJlbnQgbW9kZWwuIA0K DQpbS09dTGlrZSB0aGlzPw0KDQogICAgY29udGFpbmVyIGwzdnBuLXN2YyB7DQogICAgICAgIGxp c3QgdnBuLXN2YyB7DQogICAgICAgICAgICBrZXkgdnBuLWlkOw0KDQogICAgICAgICAgICBsZWFm IHZwbi1pZCB7DQogICAgICAgICAgICAgICAg4oCmDQogICAgICAgICAgICB9DQogICAgICAgICAg ICAuLi4NCiAgICAgICAgICAgIGxpc3QgZXh0cmFuZXQtdnBuLXBvbGljeSB7DQogICAgICAgICAg ICAgICAga2V5IHZwbi1pZDsNCiAgICAgICAgICAgICAgICBsZWFmIHZwbi1pZCB7DQogICAgICAg ICAgICAgICAgICAgIHR5cGUgc3ZjLWlkOw0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAg IH0NCiAgICAgICAgICAgIC4uLg0KICAgICAgICB9DQogICAgICAgIC4uLg0KICAgIH0NCltBaWp1 biBXYW5nXTogWWVzLg0KDQpUaGlzIGNhbiBzb2x2ZSB0aGUgaW5pdGlhbCBzY2VuYXJpbyB0aGF0 IHByb3Bvc2VkIGJ5IEtlbmljaGkgYXQgdGhlIGJlZ2lubmluZyBvZiBvdXIgZGlzY3Vzc2lvbi4g V2hlbiB0aGUgb3JjaGVzdHJhdG9yIHJlY2VpdmVzIHRoZSBpbmZvcm1hdGlvbiBkZWZpbmVkIGlu ICJleHRyYW5ldC12cG4tcG9saWN5IiwgaXQgY2FuIGFsbG9jYXRlIG5ldyByb3V0ZS10YXJnZXQg Zm9yIHRoZSBpbnZvbHZlZCBWUE5zIGFuZCBzZXQgdGhlbSBpbiB0aGUgY29uZmlndXJhdGlvbiBz dGFuemEgb2YgZWFjaCByb3V0ZXIuDQoNCiANCg0KRm9yIHRoZSByZWxhdGlvbnNoaXAgb2YgbGlz dCAidnBuLXN2YyIgYW5kIGxpc3QgInNpdGVzIiwgSSBzdGlsbCBzdWdnZXN0IHdlIHB1dCB0aGUg bGlzdCAic2l0ZSIgdW5kZXIgdGhlICJ2cG4tc3ZjIiwgdGhlIHJlYXNvbiBmb3IgZG9pbmcgdGhp cyBpcyBhcyBiZWxvdzoNCg0KMS4gdGhlIHNlcnZpY2UgbW9kZWwgbXVzdCBiZSBzZXJ2aWNlIG9y aWVudGVkLiBJZiBvbmUgc2l0ZSBiZWxvbmdzIHRvIHNldmVyYWwgdnBucywgd2Ugc2hvdWxkIGFj aGlldmUgdGhlIGdvYWwgYnkgZGVmaW5pbmcgc2V2ZXJhbCBzZXJ2aWNlIGluc3RhbmNlcy4NCg0K W0tPXSBJIGNhbid0IGFncmVlIHRoaXMuIFRoZSBjYXNlIHRoYXQgYSBzaXRlIGJlbG9uZ3MgdG8g bXVsdGlwbGUgdnBucyBpcyBhbHNvIGEgdmVyeSBjb21tb24gc2VydmljZSB1c2UgY2FzZSwgdGhl biB0aGUgc2VydmljZSBtb2RlbCBtdXN0IGRlc2lnbiB0aGlzIGFwcHJvcHJpYXRlbHkuDQpGb3Ig ZWFzeSB1c2Ugb2YgYSBzZXJ2aWNlIG1vZGVsIGFuZCB0byBhdm9pZCB0aGUgbWlzY29uZmlndXJh dGlvbiBhbmQgaW5jb25zaXN0ZW5jeSwgd2UgaGF2ZSB0byBleGNsdWRlIGR1cGxpY2F0ZSBjb25m aWd1cmF0aW9uIGZvciB0aGUgc2FtZSBpbmZvcm1hdGlvbiwgZGF0YSBub2RlIGluc3RhbmNlLCBh cyBtdWNoIGFzIHBvc3NpYmxlLiBUaGVuLCBJIHByb3Bvc2VkIHRvIHJlbW92ZSByZXBldGl0aXZl IGRlZmluaXRpb25zIG9mIGEgdnBuIHdoaWNoIGNhbiBiZSBpbXBsaWNpdGx5IHVuaXF1ZWx5IGlk ZW50aWZpZWQgaW4gYSBzYW1lIHRyYW5zYWN0aW9uLiBCdXQsIHRoYXQgZXZlbnR1YWxseSBjYW1l IG5vdCB0byBtYWtlIHNlbnNlIGZvciByZXN0Y29uZi4NCkluIHRoYXQgc2Vuc2UsIEkgYmFzaWNh bGx5IHByZWZlciB0aGUgY3VycmVudCBtb2RlbC4NCltBaWp1biBXYW5nXTogZm9yIHNpdGVzIHRo YXQgYmVsb25nIHRvIHNldmVyYWwgdnBucywgYmVjYXVzZSB3ZSBkZWZpbmUgInZwbi1zdmMiIGFz IGxpc3QsIHRoZW4gaXQgY2FuIGluY2x1ZGUgZGlmZmVyZW50IGl0ZW1zLCBlYWNoIHZwbi1zdmMg aXRlbSBjYW4gZGVmaW5lIGl0cyBvd24gc2l0ZXMgY292ZXJhZ2UgaW5mb3JtYXRpb24uIFRoZXJl IGlzIGFsc28gbm8gZHVwbGljYXRlIGNvbmZpZ3VyYXRpb24gZm9yIHRoaXMgc29sdXRpb24uIFdo YXQncyB0aGUgcHJvYmxlbSB0aGVuIGZvciB0aGlzIGFycmFuZ2VtZW50PyANCg0KDQoyLiBUaGUg YXR0cmlidXRlcyBvZiAic2l0ZXMiLCBzdWNoIGFzICJtYXhpbXVtLXJvdXRlcyIsICJzZWN1cml0 eSIsICJzZXJ2aWNlIiwgInJvdXRpbmctcHJvdG9jb2xzIiwic2l0ZS1uZXR3b2stYWNjZXNzZXMi IGV0Yy4gYXJlIGFsbCBzZXJ2aWNlL3NpdGUgcm9sZSByZWxhdGVkLCB0aGF0IGlzIHRvIHNheSwg aWYgdGhlIHNpdGUgcm9sZSBjaGFuZ2VkLCBhbGwgb2YgdGhlc2UgYXR0cmlidXRlZCBtYXkgYmUg Y2hhbmdlZCBhY2NvcmRpbmdseS4NCg0KDQpbS09dIEkgYmFzaWNhbGx5IGFncmVlLiBUaGUgYXR0 cmlidXRlcyB0aWVkIHRvIGEgd2hvbGUgdnBuIGFuZCBnbG9iYWxseSBhcHBsaWVkIHRvIGFsbCB0 aGUgc2l0ZXMgdW5kZXIgdGhlIHZwbiBzaG91bGQgYmUgZGVmaW5lZCB3aXRoIHRoZSB2cG4gZGVm aW5pdGlvbi4NCg0KDQozLkZvciBjb250YWluZXIgInZwbiBwb2xpY3kiIHRoYXQgdW5kZXIgbGlz dCAic2l0ZXMiIGluIGN1cnJlbnQgbW9kZWwsIHRoZXJlIGFyZSB0d28gaW5mb3JtYXRpb24gZGVm aW5lZCwgb25lIGlzICJmaWx0ZXIiIGZvciBwcmVmaXggZmlsdGVyaW5nLCBhbm90aGVyIGlzICJz aXRlLXJvbGUiLiBJIHN1Z2dlc3Qgd2Ugc3BsaXQgaXQsIHB1dCB0aGUgbGVhZiAic2l0ZS1yb2xl IiB1bmRlciBsZWFmICJzaXRlLWlkIiBkaXJlY3RseSwgYW5kIGNoYW5nZSB0aGUgbmFtZSBvZiAi dnBuLXBvbGljeSIgdG8gInNpdGUtcHJlZml4LXBvbGljeSIuIA0KDQogDQoNClRoZSBmaW5hbCBz dWdnZXN0IHN0cnVjdHVyZSBvZiB0aGUgTDNWUE4geWFuZyBtb2RlbCB3aWxsIGJlIGxvb2sgbGlr ZSB0aGUgYmVsbG93LCBJIHVuZGVybGluZSB0aGUgY2hhbmdlZCBwb3NpdGlvbnMgZnJvbSB0aGUg Y3VycmVudCBsM3ZwbiBZYW5nIE1vZGVsDQoNCiANCg0KQ29udGFpbmVyIEwzdnBuLXN2Yw0KDQog ICBMaXN0IHZwbi1zdmMNCg0KICAgTGVhZiB2cG4taWQNCg0KICAgTGVhZiBjdXN0b21lci1uYW1l DQoNCiAgIExlYWYgdG9wb2xvZ3kNCg0KICAgTGlzdCBleHRyYW5ldC12cG4tcG9saWN5DQoNCiAg IENvbnRhaW5lciBjbG91ZC1hY2Nlc3MNCg0KICAgTGlzdCBtdWx0aWNhc3QNCg0KICAgTGVhZiBt cGxzDQoNCiAgIExpc3QgdHJhbnNwb3J0LWNvbnRyYWludHMNCg0KICAgDQoNCiAgIExpc3Qgc2l0 ZXMNCg0KICAgICBMZWFmIHNpdGUtaWQNCg0KICAgICBMZWFmIHNpdGUtcm9sZQ0KDQogICAgIGxl YWYgYXBwbHktdGVtcGxhdGUNCg0KICAgICAuLi4gLi4uDQoNCiAgICAgLi4uIC4uLg0KDQogICAg IENvbnRhaW5lciBtYW5hZ2VudA0KDQogICAgIENvbnRhaW5lciBzaXRlLXByZWZpeC1wb2xpY3kN Cg0KICAgICBDb250YWluZXIgbWF4aW11bS1yb3V0ZXMNCg0KICAgICBDb250YWluZXIgc2VjdXJp dHkNCg0KICAgICAuLi4gLi4uDQoNCiAgICAgLi4uIC4uLg0KDQogICAgIFNpdGUtbmV0d29yay1h Y2Nlc3MgDQoNCiANCg0KIA0KDQpXaGV0aGVyIGlzIGl0IG1vcmUgcmVhc29uYWJsZT8gDQoNCiAN Cg0KIA0KDQpCZXN0IFJlZ2FyZHMuDQoNCiANCg0KQWlqdW4gV2FuZw0KDQogDQoNCkNoaW5hIFRl bGVjb20gQ29ycG9yYXRpb24gTGltaXRlZCBCZWlqaW5nIFJlc2VhcmNoIEluc3RpdHV0ZSANCg0K TmV0d29yayBSZXNlYXJjaCBhbmQgT3BlcmF0aW9uIFN1cHBvcnQgRGVwYXJ0bWVudA0KDQogDQoN CiANCg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTDNzbSBbbWFpbHRv Omwzc20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE9nYWtpLCBLZW5pY2hpDQpTZW50 OiBUaHVyc2RheSwgRmVicnVhcnkgMTgsIDIwMTYgOTowOCBBTQ0KVG86IGwzc21AaWV0Zi5vcmcN ClN1YmplY3Q6IFtMM3NtXSBJc3N1ZSAjMTAgUkU6IEwzU00gaW50ZXJpbSBtZWV0aW5nIG1pbnV0 ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KIA0KDQpIaSBTdGVwaGFuZSBh bmQgQWxsLA0KDQogDQoNCkFzIGZvciBpc3N1ZSAjMTAgaXRzZWxmLCB0aGUgZm9sbG93aW5nIHNv bHV0aW9uIGNhbiBiZSBhY2NlcHRhYmxlIGZvciB1cy4NCg0KIA0KDQo+T25lIHByb3Bvc2FsIGNv dWxkIGJlIHRvIG5vdCBjYWxsIHRoaXMgVlBOIHBvbGljeSwgYnV0IGNyZWF0aW5nIGENCg0KPmNv bnRhaW5lciAiZXh0cmFuZXQtdnBuLXBvbGljeSIgYXQgdnBuIGxldmVsIHdoaWNoIHdpbGwgbWFu ZGF0ZSBhbiBleHRyYW5ldCBWUE4gYXJjaGl0ZWN0dXJlIGZyb20gYSBjb25maWd1cmF0aW9uIHBv aW50IG9mIHZpZXcsIGRlZHVjaW5nIGF1dG9tYXRpY2FsbHkgdGhlIGFwcHJvcHJpYXRlIFJUIHJ1 bGVzIHRvIGFkZCAobGlrZSBjcmVhdGluZyBhIG5ldyBwYWlyIG9mIFJUcykuDQoNCiANCg0KV2hh dCBtb2RlbCBpcyBpbiB5b3VyIG1pbmQ/IEkgY2FuJ3Qgc2VlIHdoYXQgIiJleHRyYW5ldC12cG4t cG9saWN5IiBhdCB2cG4iIG1lYW5zLg0KDQpMaWtlIHRoaXM/DQoNCiANCg0KPHZwbi1zdmM+DQoN CiAgIC4uLg0KDQogICA8dnBuLXBvbGljeT4NCg0KICAgICAgIDxlbnRyaWVzPg0KDQogICAgICAg ICAgIDxpZD4xPC9pZD4NCg0KICAgICAgICAgICA8dnBuPg0KDQogICAgICAgICAgICAgICA8dnBu LWlkPlZQTjE8L3Zwbi1pZD4NCg0KICAgICAgICAgICA8L3Zwbj4NCg0KICAgICAgICAgICA8ZXh0 cmFuZXQtdnBuLXBvbGljeT4NCg0KICAgICAgICAgICAgICAgPGV4dHJhbmV0LXZwbj4NCg0KICAg ICAgICAgICAgICAgICAgIDx2cG4taWQ+VlBOMjwvdnBuLWlkPg0KDQogICAgICAgICAgICAgICA8 L2V4dHJhbmV0LXZwbj4NCg0KICAgICAgICAgICA8L2V4dHJhbmV0LXZwbi1wb2xpY3k+DQoNCiAg ICAgICA8L2VudHJpZXM+DQoNCiAgIDwvdnBuLXBvbGljeT4NCg0KICAgLi4uDQoNCjwvdnBuLXN2 Yz4NCg0KIA0KDQpUaGFua3MsDQoNCktlbmljaGkNCg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnIDxtYWls dG86bDNzbS1ib3VuY2VzQGlldGYub3JnPiBdIE9uIEJlaGFsZiBPZiBzdGVwaGFuZS5saXRrb3dz a2lAb3JhbmdlLmNvbSA8bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiANCg0K U2VudDogTW9uZGF5LCBEZWNlbWJlciAwNywgMjAxNSAxMTo0NSBQTQ0KDQpUbzogT2dha2ksIEtl bmljaGk7ICdBaWp1biBXYW5nJzsgJ1FpbiBXdSc7IGwzc21AaWV0Zi5vcmcgPG1haWx0bzpsM3Nt QGlldGYub3JnPiANCg0KQ2M6IGFkcmlhbkBvbGRkb2cuY28udWsgPG1haWx0bzphZHJpYW5Ab2xk ZG9nLmNvLnVrPiANCg0KU3ViamVjdDogUmU6IFtMM3NtXSBMM1NNIGludGVyaW0gbWVldGluZyBt aW51dGVzIG9uIFRodXJzZGF5IEwzU00gaW50ZXJpbSBzZXNzaW9uDQoNCiANCg0KSGkgS2VuaWNo aSwNCg0KIA0KDQpSZWdhcmRpbmcgeW91ciBwcm9wb3NhbCBvZiBoYXZpbmcgYSBzaW1wbGUgVlBO IHBvbGljeSBpbiB0aGUgdnBuLXN2YyBjb250YWluZXIsIEkgZG8gc2VlIGFuIGlzc3VlLiBPbmUg b2YgdGhlIGtleSBwb2ludCBvZiB0aGUgVlBOIHBvbGljeSBpcyB0byBleHByZXNzIHRoZSByb2xl IG9mIHRoZSBzaXRlIGluIHRoZSB0YXJnZXQgVlBOIHRvcG9sb2d5Lg0KDQpJZiB3ZSBkbyBhIHZw biBwb2xpY3kgYXQgVlBOIGxldmVsLCB3ZSBjYW5ub3QgYW55bW9yZSBkZXNjcmliZSBzaXRlIHJv bGVzIGluIHRoZSB0YXJnZXQgVlBOIHdoaWNoIGNhdXNlcyBhbiBpc3N1ZS4NCg0KSW4gYW4gaWRl YWwgd29ybGQgd2hlcmUgYWxsIFZQTnMgYXJlIGFueSB0byBhbnksIHRoZSBzaXRlIHJvbGUgaXMg YWx3YXlzIHRoZSBzYW1lIGFuZCB0aGVyZSBpcyBubyBpc3N1ZSwgYnV0IGxldCdzIHRoaW5rIGFi b3V0IHNvbWVvbmUgdHJ5aW5nIHRvIHVzZSB0aGUgdnBuLXBvbGljeSAoYXQgdnBuIGxldmVsKSB0 byBjb25uZWN0IHRvIGEgSHViICYgU3Bva2UgVlBOLCBob3cgZG8geW91IGRlZHVjZSB0aGUgcm9s ZXMgb2YgdGhlIHNpdGVzID8NCg0KIA0KDQpPbmUgcHJvcG9zYWwgY291bGQgYmUgdG8gbm90IGNh bGwgdGhpcyBWUE4gcG9saWN5LCBidXQgY3JlYXRpbmcgYSBjb250YWluZXIgImV4dHJhbmV0LXZw bi1wb2xpY3kiIGF0IHZwbiBsZXZlbCB3aGljaCB3aWxsIG1hbmRhdGUgYW4gZXh0cmFuZXQgVlBO IGFyY2hpdGVjdHVyZSBmcm9tIGEgY29uZmlndXJhdGlvbiBwb2ludCBvZiB2aWV3LCBkZWR1Y2lu ZyBhdXRvbWF0aWNhbGx5IHRoZSBhcHByb3ByaWF0ZSBSVCBydWxlcyB0byBhZGQgKGxpa2UgY3Jl YXRpbmcgYSBuZXcgcGFpciBvZiBSVHMpLiBUaGlzIG1lYW5zIHRoYXQgdGhlIHVzYWdlIGlzIHJl YWxseSBsaW1pdGVkIHRvICJzaW1wbGUiIGV4dHJhbmV0LXZwbnMgYW5kIGl0IGRvZXMgbm90IHJl cGxhY2Ugbm9yIGNvbXBldGUgd2l0aCB0aGUgVlBOIHBvbGljeSBhdCBzaXRlIGxldmVsLg0KDQog DQoNCkNvdWxkIGl0IGJlIGEgZ29vZCBjb21wcm9taXNlID8NCg0KIA0KDQpTdGVwaGFuZQ0KDQog DQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogT2dha2ksIEtlbmlj aGkgW21haWx0bzprZS1vb2dha2lAa2RkaS5jb20gPG1haWx0bzprZS1vb2dha2lAa2RkaS5jb20+ IF0NCg0KU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDA1LCAyMDE1IDA2OjIzDQoNClRvOiBMSVRL T1dTS0kgU3RlcGhhbmUgU0NFL09JTklTOyAnQWlqdW4gV2FuZyc7ICdRaW4gV3UnOyBsM3NtQGll dGYub3JnIDxtYWlsdG86bDNzbUBpZXRmLm9yZz4gDQoNCkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVr IDxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4gDQoNClN1YmplY3Q6IFJFOiBbTDNzbV0gTDNT TSBpbnRlcmltIG1lZXRpbmcgbWludXRlcyBvbiBUaHVyc2RheSBMM1NNIGludGVyaW0gc2Vzc2lv bg0KDQogDQoNCkRlYXIgU3RlcGhhbmUgYW5kIEFsbCwNCg0KIA0KDQpJIGRvbid0IHNheSB0aGF0 IHNpdGVzICptdXN0KiBtb3ZlIHVuZGVyIHZwbi1zdmMgYmVjYXVzZSBJIHVuZGVyc3RhbmQgc3Rl cGhhbmUncyB1c2UgY2FzZS4NCg0KQnV0IHdlIGFscmVhZHkgaGF2ZSB2cG4tc3ZjIGFuZCBzb21l IHBhcmFtZXRlcnMgdW5kZXIgdGhpcyBhcmUgZ2xvYmFsbHkgYXBwbGllZCB0byBhbGwgdGhlIHNp dGVzIGV2ZW4gaW4gdGhlIGN1cnJlbnQgbW9kZWwuDQoNCiANCg0KSXQgZGVwZW5kcyBvbiBvcGVy YXRvcidzIHVzZSBjYXNlIHdoaWNoIGlzIHNpdGUtb3JpZW50ZWQgb3IgdnBuLW9yaWVudGVkIHNl cnZpY2UuDQoNCk91ciBzZXJ2aWNlIGlzIHZwbi1vcmllbnRlZCwgc2l0ZSBoYXMgdGhlIG5hdGl2 ZSBWUE4uIFRoZW4sIEkgd291bGQganVzdCBsaWtlIHlvdSB0byBhbGxvdyBvdGhlciBnbG9iYWwg b3B0aW9ucyB0byB2cG4tc3ZjLg0KDQogDQoNClRoYW5rcywNCg0KS2VuaWNoaQ0KDQogDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFu Z2UuY29tIDxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+ICBbbWFpbHRvOnN0 ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIDxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb20+IF0NCg0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAwNCwgMjAxNSA4OjE3IFBNDQoN ClRvOiBBaWp1biBXYW5nOyAnT2dha2ksIEtlbmljaGknOyAnUWluIFd1JzsgbDNzbUBpZXRmLm9y ZyA8bWFpbHRvOmwzc21AaWV0Zi5vcmc+IA0KDQpDYzogYWRyaWFuQG9sZGRvZy5jby51ayA8bWFp bHRvOmFkcmlhbkBvbGRkb2cuY28udWs+IA0KDQpTdWJqZWN0OiBSRTogW0wzc21dIEwzU00gaW50 ZXJpbSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0K IA0KDQpIaSwNCg0KIA0KDQpJJ20gYWdhaW5zdCB0aGlzIHByb3Bvc2FsLCBhcyBJIGRvIG5vdCB3 YW50IHRvIGNyZWF0ZSBhbnkgZGVwZW5kZW5jeSBiZXR3ZWVuIGEgcGFydGljdWxhciBWUE4gYW5k IGEgbGlzdCBvZiBzaXRlcy4NCg0KQSBzaXRlIGNhbiBiZWxvbmcgdG8gbXVsdGlwbGUgVlBOcyB3 aXRoIGFueSBraW5kIG9mIHRvcG9sb2d5LCBpZiB3ZSBhdHRhY2ggdGhlIHNpdGUgdG8gYSBzaW5n bGUgVlBOLCB3ZSBjb21lIGJhY2sgdG8gdGhlIG5vdGlvbiBvZiAibmF0aXZlIFZQTiIgd2UgaGFk IGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIG1vZGVsIHdoaWNoIHdhcyBoYXJkIHRvIHVuZGVyc3Rh bmQgYW5kIHNvIHdhcyByZW1vdmVkLg0KDQogDQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCg0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRv Omwzc20tYm91bmNlc0BpZXRmLm9yZz4gXSBPbiBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KDQpTZW50 OiBGcmlkYXksIERlY2VtYmVyIDA0LCAyMDE1IDAyOjQ0DQoNClRvOiAnT2dha2ksIEtlbmljaGkn OyAnUWluIFd1JzsgbDNzbUBpZXRmLm9yZyA8bWFpbHRvOmwzc21AaWV0Zi5vcmc+IA0KDQpDYzog YWRyaWFuQG9sZGRvZy5jby51ayA8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+IA0KDQpTdWJq ZWN0OiBSZTogW0wzc21dIEwzU00gaW50ZXJpbSBtZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkg TDNTTSBpbnRlcmltIHNlc3Npb24NCg0KIA0KDQpEZWFyIGFsbDoNCg0KIA0KDQpDYW4gd2UgcHV0 IHRoZSBsaXN0ICJzaXRlcyIgd2l0aGluIHRoZSBsaXN0ICJ2cG4tc3ZjIiwgYW5kIGRlZmluZSB0 aGUgZ2VuZXJhbCB2cG4gcG9saWN5IGZvciBhbGwgc2l0ZXMgdGhhdCB3aXRoaW4gdGhlIGNvcnJl c3BvbmRpbmcgdnBuIHNlcnZpY2UgaW5zdGFuY2U/DQoNCklmIGRvaW5nIHNvLCBzb21lIGVudHJp ZXMgd2l0aGluIHRoZSBjdXJyZW50IGxpc3QgInNpdGVzIiBjYW4gYWxzbyBiZSBkcmFnZ2VkIG91 dCBmb3IgZ2VuZXJhbCB1c3VhbCBwdXJwb3NlcywgZm9yIGV4YW1wbGUsICJtYXhpbXVtLXJvdXRl cyIsICJzZWN1cml0eSIgZXRjLiBUaGVzZSBwYXJhbWV0ZXJzIGFyZSBvZnRlbiBhbGwgc2FtZSBm b3IgZXZlcnkgc2l0ZSB3aXRoaW4gb25lIFZQTiBzZXJ2aWNlIGluc3RhbmNlLiANCg0KIA0KDQpJ ZiBzb21lIHNpdGVzIGhhdmUgc3BlY2lhbCByZXF1aXJlbWVudHMsIHdlIGNhbiBhY2hpZXZlIHRo aXMgYnkgdXNpbmcgc29tZSBzcGVjaWFsICJzaXRlLXZwbi1wb2xpY3kiIHdpdGhpbiB0aGUgY29y cmVzcG9uZGluZyBzaXRlIGRlZmluaXRpb24uDQoNCklzIHRoaXMgbW9yZSBhY2NlcHRhYmxlIGZv ciBjdXN0b21lcnM/DQoNCiANCg0KIA0KDQpCZXN0IFJlZ2FyZHMuDQoNCiANCg0KQWlqdW4gV2Fu Zw0KDQogDQoNCkNoaW5hIFRlbGVjb20gQ29ycG9yYXRpb24gTGltaXRlZCBCZWlqaW5nIFJlc2Vh cmNoIEluc3RpdHV0ZSBJbnRlbGxpZ2VudCBOZXR3b3JrIFByb2R1Y3QgTGluZQ0KDQogDQoNCiAN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20t Ym91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZz4gXSBPbiBCZWhh bGYgT2YgT2dha2ksIEtlbmljaGkNCg0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAwNCwgMjAxNSA5 OjAyIEFNDQoNClRvOiAnUWluIFd1JzsgbDNzbUBpZXRmLm9yZyA8bWFpbHRvOmwzc21AaWV0Zi5v cmc+IA0KDQpDYzogYWRyaWFuQG9sZGRvZy5jby51ayA8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28u dWs+IA0KDQpTdWJqZWN0OiBSZTogW0wzc21dIEwzU00gaW50ZXJpbSBtZWV0aW5nIG1pbnV0ZXMg b24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KIA0KDQpEZWFyIEFsbCwNCg0KIA0K DQpJdCB3YXMgZ29vZCBoYXZpbmcgZGlzY3Vzc2lvbi4NCg0KIA0KDQpBcyBmb3IgaXNzdWUjMTAs IHRoZSBvYmplY3RpdmUgYW5kIHByb2JsZW0gd2UgZGlzY3Vzc2VkIGluIHRoZSBtZWV0aW5nIGFz IGZvbGxvd3MuDQoNCiANCg0KVGhlIG9iamVjdGl2ZSBpcyB0byBwcm92aWRlIHBlci1WUE4gZXh0 cmFuZXQgc2VydmljZSB3aGljaCBjb25uZWN0cyB0d28gZGlmZmVyZW50IFZQTnMgKGUuZy4gVlBO MSBhbmQgVlBOMikuIEl0IG1lYW5zIHRoYXQgYW55IHNpdGVzIGluIFZQTjEgY2FuIGFjY2VzcyB0 byBhbnkgc2l0ZXMgaW4gVlBOMi4NCg0KVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgY3VycmVudCBt b2RlbCBtdXN0IHVwZGF0ZSB2cG4tcG9saWN5IHVuZGVyIGFsbCB0aGUgc2l0ZXMgYmVsb25nIHRv IHRoZXNlIHR3byBWUE5zIGluIG9yZGVyIHRvIG9mZmVyIHRoaXMgc2VydmljZS4gRXNwZWNpYWxs eSB3aGVuIHRoaXMgbW9kZWwgaXMgdXNlZCBhcyBhIGN1c3RvbWVyIHNlbGYtY29udHJvbCBBUEks IGl0J3Mgbm90IGdvb2QgaWRlYSB0byByZXF1aXJlIGN1c3RvbWVycyB0byB1cGRhdGUgdGhlIGlu Zm9ybWF0aW9uIG9mIGFsbCB0aGUgc2l0ZXMuIChJdCdzIG5vdCBhYnN0cmFjdGVkIHdheSwgYSBz ZXJ2aWNlIG1vZGVsIHNob3VsZCBwcm92aWRlIHdoYXQgdGhlIGNvbnN1bWVyIHdhbnRzLCBub3Qg aG93LikgSWYgYSBzZXJ2aWNlIG9yIGN1c3RvbWVyIHJlcXVpcmVzIHRvIGNvbnRyb2wgcGVyLXNp dGUgdnBuLXBvbGljeSwgdGhhdCBvZiBjdXJyZW50IG1vZGVsIHNob3VsZCBiZSB1c2VkIHdpdGhv dXQgc2V0dGluZyBwZXItVlBOIHZwbi1wb2xpdHkuIEl0IGRlcGVuZHMgb24gZWFjaCBvcGVyYXRv cidzIHNlcnZpY2UuDQoNClN0ZXBoYW5lIHByb3Bvc2VkIHRvIHVzZSBhcHBseS10ZW1wbGF0ZSwg YnV0IGl0IHN0aWxsIGNhbm5vdCBzb2x2ZSB0aGUgcHJvYmxlbS4gV2hlbiBlYWNoIFZQTiBhbHJl YWR5IGhhcyBhIGxhcmdlIG51bWJlciBvZiBzaXRlcyBhbmQgd2FudCB0byBjb25uZWN0IGVhY2gg b3RoZXIgZm9yIHRoZSBmaXJzdCB0aW1lLCBib3RoIFZQTnMgbXVzdCB1cGRhdGUgdGhlc2Ugc2l0 ZXMgdG8gYXBwbHkgYXBwbHktdGVtcGxhdGUgb24gdGhlIGN1cnJlbnQgbW9kZWwuDQoNCiANCg0K VGhhbmtzLA0KDQpLZW5pY2hpDQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0K RnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOmwzc20tYm91 bmNlc0BpZXRmLm9yZz4gXSBPbiBCZWhhbGYgT2YgUWluIFd1DQoNClNlbnQ6IEZyaWRheSwgRGVj ZW1iZXIgMDQsIDIwMTUgMTI6NDIgQU0NCg0KVG86IGwzc21AaWV0Zi5vcmcgPG1haWx0bzpsM3Nt QGlldGYub3JnPiANCg0KQ2M6IGFkcmlhbkBvbGRkb2cuY28udWsgPG1haWx0bzphZHJpYW5Ab2xk ZG9nLmNvLnVrPiANCg0KU3ViamVjdDogW0wzc21dIEwzU00gaW50ZXJpbSBtZWV0aW5nIG1pbnV0 ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltIHNlc3Npb24NCg0KIA0KDQpIaSBhbGw6DQoNCiAN Cg0KIA0KDQpCZWxvdyBpcyB0aGUgaW5pdGlhbCB2ZXJzaW9uIG9mIGRyYWZ0IG1pbnV0ZXMgZm9y IFRodXJzZGF5IEwzU00gV0cgaW50ZXJpbSBzZXNzaW9uLg0KDQogDQoNClRoYW5rcyBEYW4gdG8g aGVscCB0YWtlIG1pbnV0ZXMuDQoNCiANCg0KRm9sa3MsIHBsZWFzZSBsZXQgdXMga25vdyBpZiB5 b3UgaGF2ZSBhbnkgY29ycmVjdGlvbi4NCg0KIA0KDQogDQoNCi1RaW4NCg0KIA0KDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQoNCiANCg0KTDNTTSBXb3JraW5nIEdyb3VwIFZpcnR1YWwgSW50ZXJp bSBNZWV0aW5nIA0KDQogDQoNClRodXJzZGF5IERlY2VtYmVyIDV0aCwgMjAxNS4gOGFtIEVhc3Qg Q29hc3QgVGltZSAoTmV3IFlvcmspDQoNCiANCg0KIA0KDQpCTFVFIFNIRUVUDQoNCiANCg0KIA0K DQpOYW1lICAgICAgICAgICAgICAgICAgICB8IEFmZmlsaWF0aW9uDQoNCiANCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQoNCiANCg0KQWRyaWFuIEZhcnJl bCAgICAgICAgICAgfCBPbGQgRG9nIENvbnN1bHRpbmcNCg0KIA0KDQpRaW4gV3UgICAgICAgICAg ICAgICAgICB8IEh1YXdlaSBUZWNobm9sb2dpZXMNCg0KIA0KDQpTdGVwaGFuZSBMaXRrb3dza2kg ICAgICB8IE9yYW5nZQ0KDQogDQoNCkx1aXMgVG9tb3Rha2kgICAgICAgICAgIHwgVmVyaXpvbg0K DQogDQoNCkRhbmllbCBLaW5nICAgICAgICAgICAgIHwgT2xkIERvZyBDb25zdWx0aW5nDQoNCiAN Cg0KU3VzYW4gSGFyZXMgICAgICAgICAgICAgfCBIdWF3ZWkgVGVjaG5vbG9naWVzDQoNCiANCg0K U2NvdHQgTWFuc2ZpZWxkICAgICAgICAgfCBFcmljc3Nvbg0KDQogDQoNCkd1IFJvbmcgICAgICAg ICAgICAgICAgIHwgQ2hpbmEgTW9iaWxlIA0KDQogDQoNCktlbmljaGkgT2dha2kgICAgICAgICAg IHwgS0RESQ0KDQogDQoNCkFpanVuIFdhbmcgICAgICAgICAgICAgIHwgQ2hpbmEgVGVsZWNvbQ0K DQogDQoNClZpY3RvciBTYW50b3MgICAgICAgICAgIHwgRXJpY3Nzb24NCg0KIA0KDQpJZ25hcyBC YWdkb25hcyAgICAgICAgICB8IA0KDQogDQoNCiANCg0KIA0KDQogDQoNCiANCg0KIA0KDQogDQoN CiANCg0KIA0KDQpNSU5VVEVTDQoNCiANCg0KIA0KDQoqIE1ldGluZyBsb2dpaXN0aWNzIGh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbDNzbS9TSnViMWFIVlFHT1FXNnJXaHRo WDBmQjhBYzggPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbDNzbS9TSnVi MWFIVlFHT1FXNnJXaHRoWDBmQjhBYzg+ICANCg0KIA0KDQoqIE1lZXRpbmcgbWF0ZXJpYWxzIGh0 dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNS8xMi8wMy9sM3NtL3By b2NlZWRpbmdzLmh0bWwgPGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0v MjAxNS8xMi8wMy9sM3NtL3Byb2NlZWRpbmdzLmh0bWw+ICANCg0KIA0KDQoqIEV0aGVycGFkIGZv ciBtaW51dGVzICh0aGlzIHBhZ2UpIGh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAw L3AvbDNzbS1pbnRlcmltLTIwMTUtMTItMDMgPGh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9y Zzo5MDAwL3AvbDNzbS1pbnRlcmltLTIwMTUtMTItMDM+IA0KDQogDQoNCiogSmFiYmVyIHVzaW5n IGwzc21AamFiYmVyLmlldGYub3JnIDxtYWlsdG86bDNzbUBqYWJiZXIuaWV0Zi5vcmc+IA0KDQog DQoNCiogQmx1ZSBzaGVldCBodHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9wL2wz c20taW50ZXJpbS0yMDE1LTEyLTAzLWJsdWVzaGVldCA8aHR0cDovL2V0aGVycGFkLnRvb2xzLmll dGYub3JnOjkwMDAvcC9sM3NtLWludGVyaW0tMjAxNS0xMi0wMy1ibHVlc2hlZXQ+IA0KDQogDQoN CiANCg0KQWdlbmRhYQ0KDQogDQoNCi0gQWRtaW5pc3RyaXZpYSAoTm90ZSBXZWxsLCBldGMpLiBh DQoNCiANCg0KLSBJbnRyb2R1Y3Rpb24NCg0KIA0KDQotIE9wZW4gSXNzdWVzIGZvciBZQU5HIERh dGEgTW9kZWwgZm9yIEwzVlBOc2VydmljZSBkZWxpdmVyeSAoZHJhZnQtaWV0Zi1sM3NtLWwzdnBu LXNlcnZpY2Vtb2RlbCkNCg0KIA0KDQpvIE9wZW4gSXNzdWVzIGRpc2N1c3Npb24gYW5kIHJlc29s dXRpb27igJMgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvbDNzbS90cmFjL3JlcG9ydC8x IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9sM3NtL3RyYWMvcmVwb3J0LzE+IA0KDQog DQoNCiANCg0KRm9yIGEgZnVsbCBsaXN0IG9mIGlzc3VlcyBhbmQgcmVzb2x1dGlvbiBwcm9wb3Nh bHMgcGxlYXNlIHNlZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8y MDE1LzEyLzAzL2wzc20vc2xpZGVzL3NsaWRlcy1pbnRlcmltLTIwMTUtbDNzbS0xLTIucGRmIDxo dHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTUvMTIvMDMvbDNzbS9z bGlkZXMvc2xpZGVzLWludGVyaW0tMjAxNS1sM3NtLTEtMi5wZGY+IA0KDQogDQoNCiANCg0KSXNz dWUjMTogV2hlbiBjdXN0b21lci1uYXQtYWRkcmVzcyBpcyB1c2VkDQoNCiANCg0KUmVzb2x1dGlv biAjMTogIExlYWYgdXNlZCB3aGVuIE5BVCBpcyByZXF1aXJlZCB0byBhY2Nlc3MgY2xvdWQgVlBO IGFuZCBjdXN0b21lciB3YW50cyB0byB1c2UgaXRzIG93bklQIGFkZHJlc3MuIElmIHByb3ZpZGVy IHByb3ZpZGVzIHRoZSBwdWJsaWMgSVAsbm8gbmVlZCB0byB1c2UgdGhlIGxlYWYNCg0KIA0KDQpT dGF0dXMgIzE6ICBDbG9zZWQgUGVuZGluZyBJLUQgdGV4dCByZXZpZXcuICAgDQoNCiANCg0KRGlz Y3Vzc2lvbiBvbiAjMTogDQoNCiANCg0KIA0KDQpBaWp1biBhc2tzIGZvciBtb3JlIGRlc2NyaXB0 aW9uIGluIHRoZSBZQU5HIG1vZGVsIGl0c2VsZg0KDQogDQoNClN0ZXBoYW5lIHNob3dzIGN1cnJl bnQgbW9kZWwNCg0KIA0KDQpBZ3JlZWQgT0sNCg0KIA0KDQogDQoNCklzc3VlIzIgOiBJZGVudGlm eSBsM3ZwbiBzdmMgdXNpbmcgaWQgb3IgbmFtZSBvciBib3RoDQoNCiANCg0KUmVzb2x1dGlvbiAj MjogIElEIGlzIGEgc3RyaW5nLCBhcyBwZXIgb3RoZXIgcHJvcGVydGllcyBpbiB0aGUgbW9kZWwN Cg0KIA0KDQpTdGF0dXMgIzI6IENsb3NlZA0KDQogDQoNCkRpc2N1c3Npb24gb24gIzI6IA0KDQog DQoNCiANCg0KQWdyZWVkIE9LDQoNCiANCg0KIA0KDQpJc3N1ZSMzOiBNIHRvIE4gYXZhaWxhYmls aXR5IHN1cHBvcnQNCg0KIA0KDQpSZXNvbHV0aW9uICMzOiBNb2RlbGluZyBzaXRlcyB1c2luZyBh IGxpc3Qgd2l0aCBhIHByaW9yaXR5LCBzbyBpbmNsdWRlIGFjY2VzcyBsaXN0IHdpdGggYSBwcmlv cml0eS4NCg0KIA0KDQpTdGF0dXMgIzM6DQoNCiANCg0KRGlzY3Vzc2lvbiBvbiAjMzogDQoNCiAN Cg0KIA0KDQpRaW4gd2FzIGFza2luZyB0aGF0IE0gdG8gTiBhdmFpbGFiaWxpdHkgaXMgc3VwcG9y dGVkIHdpdGggYWNjZXNzIGFuZCBwcmlvcml0eSBudW1iZXIuIA0KDQogDQoNClN0ZXBoYW5lIHN0 YXRlZCB0aGlzIGlzIHN1cHBvdGVkLiBUaGlzIG5ldyBwcm9wb3NhbCBhbHNvIHN1cHBvcnRzIG11 bHRpcGxlIHNpdGVzLCBhcyBhIGxpc3QuDQoNCiANCg0KUWluIGFsc28gYXNrZWQgaWYgR3JvdXAg SS1EIHdhcyBubyBsb25nZXIgbmVlZGVkLCB3aGljaCBpdCBpcyBub3QuIEFsc28gZ29vZCBzb2x1 dGlvbiBzdXBwb3J0ZWQgYnkgb3RoZXIgb3BlcmF0b3JzLg0KDQogDQoNClN0ZXBoYW5lIGFza2Vk IGlmIGZvdXIgcHJpb3JpdGllcyB3YXMgZW5vdWdoLCBvciBpZiBtb3JlIHdlcmUgbmVlZGVkLiAN Cg0KIA0KDQogDQoNClJlOiBDb250YWluZXJzL1Byb3BlcnRpZXMgZm9yIE5ldHdvcmsgQWNjZXNz IENvbmZpZ3VyYXRpb24gLSBDb25jbHVzaW9ucz8NCg0KIA0KDQogDQoNCm8gTG9jYXRpb24gLSBE aWZmZXJlbnQgc2l0ZSBJLUQ/DQoNCiANCg0KbyBRb1MgUG9saWN5IC0gUGVyIG5ldHdvcmsgYWNj ZXNzIGxpbmssIG9yIHNpdGUgaW5mb3JtYXRpb24/IFdvdWxkIFFvUyAoY29zdCkgYmUgZGlmZmVy ZW50IHBlciBhY2Nlc3NsaW5rIG9yIHNpdGU/IEV4YW1wbGUgb2YgUHJpbWFyeSBhbmQgQmFja3Vw IGxpbmtzIGdpdmVuLiANCg0KIA0KDQpvIEJhbmR3aWR0aCAtIE1vdmVkIHRvIGFjY2VzcyBsaW5r IGdyb3VwIA0KDQogDQoNCm8gTWF4aW11bSBSb3V0ZXMgLSANCg0KIA0KDQpTZWN1cml0eSwgcm91 dGluZywgYW5kIHNlcnZpY2VzIGFyZSBkdXBsaWNhdGVkIHdpdGggaW5oZXJpdGFuY2UNCg0KIA0K DQogDQoNCiANCg0KSXNzdWUjNDogc2l0ZS1zZXJ2aWNlLWNsb3VkIGFjY2VzcyBhcyBncm91cGlu Zw0KDQogDQoNClJlc29sdXRpb24gIzQgQWxyZWFkeSByZXNpbHZlZCBhcyBhIHNlcGFyYXRlIGdy b3VwaW5nDQoNCiANCg0KU3RhdHVzICM0OiBDbG9zZWQNCg0KIA0KDQpEaXNjdXNzaW9uIG9uICM0 OiANCg0KIA0KDQogDQoNCklzc3VlIzU6IE11bHRpY2FzdCBzdXBwb3J0IGFzIHJhaXNlZCBieSBF cmljIFJvc2VuDQoNCiANCg0KUmVzb2x1dGlvbiAjNTogOiBOZXcgInByb3ZpZGVyIG1hbmFnZWQi IHByb3BlcnR5LCBhbmQgaW4gU2l0ZSBQcm9wZXJ0aWVzICJwcm9wZXJ0eS10eXBlIiAgYWRkZWQN Cg0KIA0KDQpTdGF0dXMgIzU6IFNvbHV0aW9uIHByb3Bvc2VkLiANCg0KIA0KDQpEaXNjdXNzaW9u IG9uICM1OiANCg0KIA0KDQogDQoNClN0ZXBoYW5lIHdpbGwgcHJvdmlvZGUgbmV3IHByb3BlcnR5 IHByb3Bvc2FscyB3aWxsIGJlIHByb3ZpZGVkIHRvIEVyaWMgZm9yIHJldmlldy4gDQoNCiANCg0K IA0KDQpJc3N1ZSM2OiBJbnZlbnRvcnkgb3BlcmF0aW9uYWwgc3RhdGUNCg0KIA0KDQpSZXNvbHV0 aW9uICM2OiBJbmNsdWRlIGEgbmV3IGNvbnRhaW5lciBmb3IgaW52ZW50b3J5IHN0YXRlLCBvciBh biBSUEMgY2FsbCAoc2l0dGluZyBhYm92ZSB0aGUgc2VydmljZSBvcmNoZXN0cmF0b3IpIHRvIHJl dHJpZXZlIGludmVudG9yeSBzdGF0ZS4gDQoNCiANCg0KU3RhdHVzICM2OiBOZWVkIHRvIHByb3Bv c2UgdG8gdGhlIFdHIGFuZCBhZ3JlZSBzb2x1dGlvbi4NCg0KIA0KDQpEaXNjdXNzaW9uIG9uICM2 OiANCg0KIA0KDQogDQoNCkx1aXMgYXNrZWQgd291bGQgdGhpcyBpbmZvIGJlIGNvbGxlY3RlZCBm cm9tIHByb3Zpc2lvbiBzdGF0ZT8gU3RlcGhhbmUgc3VnZ2VzdGVkIHRoaXMgd291bGQgbm90IGJl IGF2YWlsaWJsZS4gDQoNCiANCg0KQWRyaWFuIG9ic2VydmVkIHRoYXQgdGhlIGNvZGUgdXNlZCB0 byBjb252ZXJ0IHRoZSBtb2RlbCBpbnRvIGEgc2VydmljZSByZXF1ZXN0IG1heSBub3QgdXRpbGlz ZSB0aGlzIGludmVudG9yeSBpbmZvcm1hdGlvbiBjYXBhYmlsaXR5LiBTdWUgbWVudGlvbmVkIHRo YXQgb3RoZXJzIGhhdmUgbWVudGlvbmVkIGJ5IGEgdmVuZG9yIHRoYXQgaXQgd291bGQgYmUgdXNl ZnVsIHRvIGhhdmUgdGhlIGFiaWxpdHkgdG8gY29uZmlndXJlIGludmVudG9yeSBzdGF0ZS4gVGhp cyBzaG91bGQgYmUgY2xhcmlmaWVkIGJ5IHRoZSBvcGVyYXRvcnMuIA0KDQogDQoNCiANCg0KU3Rl cGhhbmUgdG8gdGFrZSBwcm9wb3NhbHMgdG8gbGlzdCBhbmQgYXNrIGFueW9uZSB3aG8gaXMgaW50 ZXJlc3RlZCBpbiBoYXZpbmcgdGhlIGZlYXR1cmUgdG8gc3VnZ2VzdCB0ZXh0Lg0KDQogDQoNCiAN Cg0KIA0KDQpJc3N1ZSM3OiBHZW5lcmljIFZBUyAtIGRvIHdlIG5lZWQgdG8gY3JlYXRlIGEgZ2Vu ZXJpYyBWQVMgY29udGFpbmVyIGFzIFZBUyBhcmUgcG9wdWxhciBpbiBMM1ZQTnM/DQoNCiANCg0K UmVzb2x1dGlvbiAjNzogU2VwYXJhdGUgZnJvbSBMM1NNDQoNCiANCg0KU3RhdHVzICM3OiBDbG9z ZWQNCg0KIA0KDQpEaXNjdXNzaW9uIG9uICM3OiANCg0KIA0KDQogDQoNCkd1IFJvbmcgaGlnaGxp Z2h0ZWQgR2VuZXJpYyBWQVMgbW9kZWwgd2hpY2ggd2FzIHByZXNlbnRlZCBhdCBJRVRGIDk0LiAN Cg0KIA0KDQogDQoNCklzc3VlIzg6IFdobyBrZWVwcyBzaXRlIGxvY2F0aW9uaW5mb3JtYXRpb24/ DQoNCiANCg0KUmVzb2x1dGlvbiAjODogVGV4dCBoYXMgYmVlbiBmaXhlZA0KDQogDQoNClN0YXR1 cyAjODogQ2xvc2VkDQoNCiANCg0KRGlzY3Vzc2lvbiBvbiAjODogDQoNCiANCg0KICAgIA0KDQog DQoNCklzc3VlIzk6IERvIHdlIG5lZWQgdG8gbW9kZWwgdHJhbnNwb3J0IGNvbnN0cmFpbnRzLCBz dWNoIGFzOiBqaXR0ZXIsIGRpc2pvaW50LCBwYXRoIGRpdmVyc2l0eT8NCg0KIA0KDQpSZXNvbHV0 aW9uICM5OiAgIFByb3Bvc2UgYSAidHJhbnNwb3J0LWNvbnN0cmFpbnQiIGdyb3VwIHdpdGggImNv bnN0cmFpbnQtdHlwZSIsICJjb25zdHJhaW50LXZhbHVlIiBhbmQgImNvbnN0cmFpbnQtbGlzdCIg KGNvbXBvc2VkIG9mIHR5cGUgYW5kIHZhbHVlcykNCg0KIA0KDQpTdGF0dXMgIzk6IEF1dGhvcnMg dG8gcHJvcG9zZSB0aGUgcmVzb2x1dGlvbiBpbiB0aGUgSS1EIGFuZCBwcm92aWRlIHRvIHRoZSBX Rw0KDQogDQoNCkRpc2N1c3Npb24gb24gIzk6ICAgIA0KDQogDQoNCiANCg0KIA0KDQpMdWlzIG1l bnRpb25lZCB0aGF0IHRoZXkgaGF2ZSBtdWx0aWNhc3QgdHJhbnNwb3J0IChtdWx0aXBsZSBzaXRl cykgYW5kIGJpLWRpcmVjdGlvbmFsIHRyYWZmaWMgYXBwbGljYXRpb25zIChmaW5hbmNpYWwpIHRo YXQgd2lsbCByZXF1aXJlIHRyYW5zcG9ydCBjb25zdHJhaW50cw0KDQogDQoNCiANCg0KRHVwbGlj YXRlIHRyYW5zcG9ydCBjb25zdHJhaW50cyBmb3IgdW5pY2FzdCBhbmQgbXVsdGljYXN0IHRvIGdp dmUgb3B0aW9ucyBmb3Igc2VwYXJhdGUgY29uZmlndXJhdGlvbi4NCg0KIA0KDQpLZWVwIHNpbmds ZSBsaXN0IGVudHJpZXMgZm9yIGVhY2ggc3JjL2RzdCBwYWlyIGV2ZW4gaW4gdGhlIG11bHRpY2Fz dCB2YXJpYW50Lg0KDQogDQoNCiANCg0KRE8gd2UgbmVlZCB0byBzdXBwb3J0IG11bHRpcGxlIGNv bnN0cmFpbnRzIG9yIGp1c3QgaGF2ZSBhIHNpbmdsZSBjb21wb3NpdGUgKG9mIG11bHRpcGxlIGNv bnN0cmFpbnRzKSwgaGF2ZSB0aGUgYWJpbGl0eSB0byBzcGVjaWZ5IGEgY29uc3RyYWludC1saXN0 Pw0KDQogDQoNCkFpanVuIHByZmVycyBsaXN0IG9mIGNvbnN0cmFpbnRzIGFuZCBtZWV0aW5nIGFn cmVlcyB0aGlzIGlzIE9LDQoNCiANCg0KIA0KDQpXaGF0IGNvbnN0cmFpbnRzIHRvIG9mZmVyPw0K DQogDQoNCkxhdGVuY3kNCg0KIA0KDQpQYXRoIGRpdmVyc3R5DQoNCiANCg0KU2l0ZSBkaXZlcnN0 eQ0KDQogDQoNCkppdHRlcg0KDQogDQoNCkNsYXNzIG9mIHNlcnZpY2Ugd2FzIHByb3Bvc2VkIGJ1 dCByZWplY3RlZA0KDQogDQoNCiANCg0KTHVpcyBoaWdobGlnaHRlZCB0aGV5IGhhdmUgYSBjdXJy ZW50IGltcGxlbWVudGF0aW9uIHRoYXQgdXNlcyB0aGUgc2ltaWxhciBwcm9wb3NhbC4gTHVpcyBh bHNvIG1lbnRpb25lZCB0aGF0IHNpdGUgZGl2ZXJzaXR5IG1pZ2h0IGFsc28gYmUgcmVxdWlyZWQs IHdvdWxkIHRoaXMgYmUgYWNoaWV2YWJsZQ0KDQogDQoNCiANCg0KIA0KDQpJc3N1ZSMxMDogVlBO ICJtZXJnaW5nIg0KDQogDQoNClJlc29sdXRpb24gIzEwOiAgICANCg0KIA0KDQpTdGF0dXMgIzEw Og0KDQogDQoNCkRpc2N1c3Npb24gb24gIzEwOiAgICANCg0KIA0KDQogDQoNClZQTiBpcyBhIHBl ciBzaXRlIHByb3BlcnR5LiANCg0KIA0KDQotIEEgc2l0ZSBjYW4gYmVsb25nIHRvbXVsdGlwbGUg VlBOcw0KDQogDQoNCi0gSG93IHRvIGhhbmRsZSBtZXJnaW5nIG9mIHR3byBWUE5zPw0KDQogDQoN Ci0gSXMgdGhpcyBhbiBpc3N1ZSB0aGUgc2VydmljZSBtb2RlbCBoYXMgdG8gZGVhbCB3aXRoPw0K DQogDQoNCiANCg0KSWYgVlBOIG1lcmdpbmcgaXMgcmVxdWlyZWQgdG8gYmUgc2VhbWxlc3MsIHRo ZW4gdGhpcyB3b3VsZCBiZSBkZXZpY2Ugc3BlY2lmaWMgYW5kIG5vdCBzZXJ2aWNlIG1vZGVsIHJl bGF0ZWQuICANCg0KIA0KDQogDQoNCiJNZXJnaW5nIiBpcyBhIGNvbmZ1c2luZyB0ZXJtLiBUaGUg b2JqZWN0aXZlIGlzIE5PVCB0byBtZXJnZSBWUE4xIGFuZCBWUE4yLg0KDQogDQoNClRoZSBvYmpl Y3RpdmUgaXMgdG8gcHJvdmlkZSBhbiBleHRyYW5ldCBzbyB0aGF0IHNvbWUgc2l0ZXMgaW4gVlBO MSBjYW4gY29ubmVjdCB0byBzb21lIHNpdGVzIGluIFZQTjIgZm9yIHNvbWUgdHJhZmZpYy4NCg0K IA0KDQpUaGlzIGNhbiBiZSBzb2x2ZWQgdXNpbmcgYSBwZXItc2l0ZSBwcm9wZXJ0eS4NCg0KIA0K DQogDQoNCkFjdGlvbjogTmVlZCB0byB1cGRhdGUgdGhpcyBpc3N1ZSB0byBtYWtlIGl0IGNsZWFy IHdoYXQgZnVuY3Rpb24gd2FzIGJlaW5nIGRpc2N1c3NlZCwgYWxzbyBTdGVwaGFuZSB3aWxsIHNl bmQgb3B0aW9ucyB0byB0aGUgd29ya2luZyBncm91cC0gbGlzdC4gDQoNCiANCg0KV2UgYXJlIHNw ZWNpZmljYWxseSBsb29raW5nIGZvciBwZW9wbGUgd2hvIG9mZmVyIGV4dHJhbmV0IGNvbm5lY3Rp b24gYmV0d2VlbiBzaXRlcyBmcm9tIGRpZmZlcmVudCBWUE5zDQoNCiANCg0KIA0KDQo9PSBPdGhl ciBJc3N1ZXMgPT0gICAgDQoNCiANCg0KIA0KDQpNb2RlbGluZyBDdXN0b21lciBTcGVjaWZpYyBJ bmZvDQoNCiANCg0KLSBDcmVhdGUgYXBwcm9waWF0ZSBjb250YWluZXJzIGZvciBQcm92aWRlciBF ZGdlIGFuZCBDdXN0b21lciBTaXRlIHJvdXRlcnMNCg0KIA0KDQotIFRoZSBjdXJyZW50ICBtb2Rl bCBjb250YWlucyByb3V0aW5nIHBhcmFtZXRyZXMgdGhhdCByZWZlciB0byBDRSBhbmQgUEUgcmVs YXRpb25zaGlwcw0KDQogDQoNCi0gR2VuZXJhbCBhZ3JlZW1lbnQgaXMgcm91dGluZyBpbmZvIHNo b3VsZCBiZSBzcGxpdCBhbmQgY3VycmVudCBwcm9wb3NhbCB3aWxsIGJlIHNlbnQgdG8gdGhlIGxp c3QgZm9yIEtlbmljaGksIGFuZCB3b3JraW5nIGdyb3VwcywgcmV2aWV3LiANCg0KIA0KDQogDQoN Cj09IENvbmNsdXNpb25zID09DQoNCiANCg0KIA0KDQotIEEgbnVtYmVyIG9mIHJlc29sdXRpb25z IGhhdmUgYmVlbiBhZ3JlZWQgYW5kIHdpbGwgYmUgdXBkYXRlZCBpbiB0aGUgSS1EDQoNCiANCg0K LSBDaGFpcnMgd291bGQgbGlrZSB0byBzZWUgcmV2aXNlZCBJLUQgYmFzZWQgb24gdGhlIGFncmVl ZCBwb2ludHMNCg0KIA0KDQotIFBsYW4gdG8gaGF2ZSBhbm90aGVyIGludGVyaW0gY2FsbCBhdCB0 aGUgZW5kIG9mIEphbnVhcnkgKDIwMTYpDQoNCiANCg0KLSBDaGFpcnMgdG8gYWRkIG5ldyB0cmFj a2VyIGl0ZW1zLCBpbmNsdWRpbmcgc2VjdXJpdHkgZm9yIGZ1dHVyZSBkaXNjdXNzaW9uLiANCg0K IA0KDQogDQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KTDNzbSBtYWlsaW5nIGxpc3QNCg0KTDNzbUBpZXRmLm9yZyA8bWFpbHRvOkwzc21A aWV0Zi5vcmc+IA0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20g PGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbT4gDQoNCiANCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KTDNzbSBtYWls aW5nIGxpc3QNCg0KTDNzbUBpZXRmLm9yZyA8bWFpbHRvOkwzc21AaWV0Zi5vcmc+IA0KDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20gPGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbDNzbT4gDQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQogDQoNCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaQ0KDQogDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3JpemF0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBG cmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBzaGFsbCBub3QgYmUgbGlhYmxlIGlmIHRoaXMgbWVzc2Fn ZSB3YXMgbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCiAN Cg0KIA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KIA0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgRnJhbmNlIFRlbGVj b20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kNCg0KIA0KDQpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXphdGlv bi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2Ug c2hhbGwgbm90IGJlIGxpYWJsZSBpZiB0aGlzIG1lc3NhZ2Ugd2FzIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkwzc20gbWFpbGluZyBsaXN0DQoNCkwzc21A aWV0Zi5vcmcgPG1haWx0bzpMM3NtQGlldGYub3JnPiANCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sM3NtIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2wzc20+IA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCkwzc20gbWFpbGluZyBsaXN0DQoNCkwzc21AaWV0Zi5vcmcgPG1haWx0bzpM M3NtQGlldGYub3JnPiANCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s M3NtIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20+IA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTDNzbSBtYWlsaW5n IGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbDNzbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KTDNzbSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbDNzbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KTDNzbSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbQ0KCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91 LgoK From nobody Thu Feb 25 00:23:45 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903441A1A5A for ; Thu, 25 Feb 2016 00:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 jayQy3TPrgoG for ; Thu, 25 Feb 2016 00:23:40 -0800 (PST) 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 9A5311A01A2 for ; Thu, 25 Feb 2016 00:23:40 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 28B4F400BF; Thu, 25 Feb 2016 09:23:39 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id EDEB01A0079; Thu, 25 Feb 2016 09:23:38 +0100 (CET) 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; Thu, 25 Feb 2016 09:23:38 +0100 From: To: Aijun Wang <13301168517@189.cn>, "l3sm@ietf.org" Thread-Topic: [L3sm] Additional Issues---site's parameter relation with specific vpn Thread-Index: AdFvcZ2IgU8kJ02yRIulOO8e+OsH+QAA1zAwAAwbQJA= Date: Thu, 25 Feb 2016 08:23:38 +0000 Message-ID: <8465_1456388619_56CEBA0B_8465_1437_1_9E32478DFA9976438E7A22F69B08FF92168CA7F9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <005d01d16f75$1107ddc0$33179940$@cn> In-Reply-To: <005d01d16f75$1107ddc0$33179940$@cn> 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: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92168CA7F9OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [L3sm] Additional Issues---site's parameter relation with specific vpn X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 08:23:43 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92168CA7F9OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Inline comments From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 03:34 To: l3sm@ietf.org Subject: [L3sm] Additional Issues---site's parameter relation with specific= vpn Hi, L3SMer: With the discussion about the current L3VPN yang model, we found there is a= nother additional issue needed to be solved. This issue will influence the = design of L3SM Yang structure as well. Issue description: In current L3VPN yang model, we define the site's variou= s parameters via several container, such as "location", "site-diversity","management","vpn-policy","maximum-rou= tes","security","service","routing-protocol","site-network-accesses" etc. F= or these containers, only the "location" is determined and has no relation = with the specific vpn id, other containers are all related with the specifi= c vpn id. That is to say, if the vpn is different, the "site-diversity","management",= "vpn-policy","maximum-routes","security","service","routing-protocol","site= -network-accesses" container will have different values, but in current Yan= g model, only the "vpn-policy" has relationship with the vpn-id. [SLI] I cannot agree, a multiVPN scenario strongly requires that each "VPN = attachment" as the same parameter this is by design because all the "VPN at= tachments" are using the same logical access. Only the vpn-policy plays wit= h the VPN attachment. I think you are confusing with subVPN where you have = a logical access per VPN with potential different parameters but this is a = different subject that is also under discussion. Solution proposal: Put the site definition or reference within the list "vp= n-svc", please see https://mailarchive.ietf.org/arch/msg/l3sm/lB4HbUVczwyyg= AScPeh4tV0EBRo So, what your consideration for this issue and solution proposal? Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network Research and Operation Support Department ___________________________________________________________________________= ______________________________________________ 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_9E32478DFA9976438E7A22F69B08FF92168CA7F9OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

=  

Inlin= e comments

=  

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Thursday, February 25, 2016 03:34
To: l3sm@ietf.org
Subject: [L3sm] Additional Issues---site's parameter relation with s= pecific vpn

 =

Hi, L3SMe= r:

&nbs= p;

With the = discussion about the current L3VPN yang model, we found there is another ad= ditional issue needed to be solved. This issue will influence the design of= L3SM Yang structure as well.

&nbs= p;

Issue des= cription: In current L3VPN yang model, we define the site’s various p= arameters via several container,

such as “locationR= 21;, “site-diversity”,”management”,”vpn-polic= y”,”maximum-routes”,”security”,”service= ”,”routing-protocol”,”site-network-accesses” etc. For these containers, only the “location” is determined a= nd has no relation with the specific vpn id, other containers are all relat= ed with the specific vpn id.

That is to say, if the vpn = is different, the “site-diversity”,”management”,= 221;vpn-policy”,”maximum-routes”,”security”,&= #8221;service”,”routing-protocol”,”site-network-acc= esses” container will have different values, but in current Yang model, only the = “vpn-policy” has relationship with the vpn-id.

[SLI] I cannot agree, a multiVPN scenario strongly requires that each = “VPN attachment” as the same parameter this is by design becaus= e all the “VPN attachments” are using the same logical access. Only the vpn-policy plays with the VPN attachment. I think you are= confusing with subVPN where you have a logical access per VPN with potenti= al different parameters but this is a different subject that is also under = discussion.

 

 

Solution = proposal: Put the site definition or reference within the list “vpn-s= vc”, please see https://mailarchive.ietf.org/arch/msg/l3sm/lB4HbUVczwyygAScPeh4tV0EBRo<= o:p>

&nbs= p;

So, what = your consideration for this issue and solution proposal?<= /p>

&nbs= p;

Best Regards.

 

Aijun Wang

 

China Telecom Corporation Limit= ed Beijing Research Institute 

Network Research and Operation Support Departm= ent

&nbs= p;

______________________________________________________________________=
___________________________________________________

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_9E32478DFA9976438E7A22F69B08FF92168CA7F9OPEXCLILMA4corp_-- From nobody Thu Feb 25 00:40:02 2016 Return-Path: <13301168517@189.cn> X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074B21A6F44 for ; Thu, 25 Feb 2016 00:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.507 X-Spam-Level: X-Spam-Status: No, score=0.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, FROM_LOCAL_DIGITS=0.001, FROM_LOCAL_HEX=0.006, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 vMxK7L5fBZs6 for ; Thu, 25 Feb 2016 00:39:57 -0800 (PST) Received: from 189.cn (mta.189.cn [121.14.53.138]) by ietfa.amsl.com (Postfix) with ESMTP id D90FD1A6F2E for ; Thu, 25 Feb 2016 00:39:56 -0800 (PST) HMM_SOURCE_IP: 10.64.8.33:43195.1854856477 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.77 (unknown [10.64.8.33]) by 189.cn (HERMES) with ESMTP id EC47A15C11A; Thu, 25 Feb 2016 16:39:44 +0800 (CST) Received: from ctbriwangaij ([219.142.69.77]) by zm-as3(MEDUSA 0.0.0.0) with ESMTP id 61649721-f374-4a66-8238-466f973fd04e for ke-oogaki@kddi.com; Thu Feb 25 16:39:52 2016 0/X-Total-Score: 0: X-FILTER-SCORE: to=<8c864e909088828c8a618c85858a4f84908e>, score=<1456389592FXXXXXqXXIXX0XqI0ZQcMjHHHHHIHHfHHgHIfgPbccdr> X-REAL-FROM: 13301168517@189.cn X-Receive-IP: 219.142.69.77 From: "Aijun Wang" <13301168517@189.cn> To: , References: <005d01d16f75$1107ddc0$33179940$@cn> <8465_1456388619_56CEBA0B_8465_1437_1_9E32478DFA9976438E7A22F69B08FF92168CA7F9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <8465_1456388619_56CEBA0B_8465_1437_1_9E32478DFA9976438E7A22F69B08FF92168CA7F9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Date: Thu, 25 Feb 2016 16:40:01 +0800 Message-ID: <00ab01d16fa8$22d4df20$687e9d60$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AC_01D16FEB.30F81F20" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdFvcZ2IgU8kJ02yRIulOO8e+OsH+QAA1zAwAAwbQJAAAELhgA== Content-Language: zh-cn Archived-At: Cc: "'Ogaki, Kenichi'" Subject: Re: [L3sm] Additional Issues---site's parameter relation with specific vpn X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 08:40:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00AC_01D16FEB.30F81F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, What we are discussing here is when one site belong to multiple vpn, will the various site's attribute will be different or definitely same. For example, one site may be hub-role in one vpn, but may be spoke-role in another vpn, and the attributes "site-diversity","management","vpn-policy","maximum-routes","security","serv ice","routing-protocol","site-network-accesses" will be different for hub/spoke site. Ogaki raised the similar issue for "site-network-accesses", please refer the thread https://mailarchive.ietf.org/arch/msg/l3sm/86TbWo1FUsKbzq9uocIv4Oh_vfw and the following exchange mail. How do you solve this issue within the current Yang model? From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Thursday, February 25, 2016 4:24 PM To: Aijun Wang; l3sm@ietf.org Subject: RE: [L3sm] Additional Issues---site's parameter relation with specific vpn Hi, Inline comments From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 03:34 To: l3sm@ietf.org Subject: [L3sm] Additional Issues---site's parameter relation with specific vpn Hi, L3SMer: With the discussion about the current L3VPN yang model, we found there is another additional issue needed to be solved. This issue will influence the design of L3SM Yang structure as well. Issue description: In current L3VPN yang model, we define the site's various parameters via several container, such as "location", "site-diversity","management","vpn-policy","maximum-routes","security","serv ice","routing-protocol","site-network-accesses" etc. For these containers, only the "location" is determined and has no relation with the specific vpn id, other containers are all related with the specific vpn id. That is to say, if the vpn is different, the "site-diversity","management","vpn-policy","maximum-routes","security","serv ice","routing-protocol","site-network-accesses" container will have different values, but in current Yang model, only the "vpn-policy" has relationship with the vpn-id. [SLI] I cannot agree, a multiVPN scenario strongly requires that each "VPN attachment" as the same parameter this is by design because all the "VPN attachments" are using the same logical access. Only the vpn-policy plays with the VPN attachment. I think you are confusing with subVPN where you have a logical access per VPN with potential different parameters but this is a different subject that is also under discussion. Solution proposal: Put the site definition or reference within the list "vpn-svc", please see https://mailarchive.ietf.org/arch/msg/l3sm/lB4HbUVczwyygAScPeh4tV0EBRo So, what your consideration for this issue and solution proposal? Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network Research and Operation Support Department ____________________________________________________________________________ _____________________________________________ 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. ------=_NextPart_000_00AC_01D16FEB.30F81F20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

What we are = discussing here is when one site belong to multiple vpn, will the = various site’s attribute will be different or definitely same. For = example, one site may be hub-role in one vpn, but may be spoke-role in = another vpn, and the attributes “site-diversity”,”management”,”= ;vpn-policy”,”maximum-routes”,”security”,&#= 8221;service”,”routing-protocol”,”site-network-ac= cesses” will be = different for hub/spoke site.  

Ogaki = raised the similar issue for “site-network-accesses”, please = refer the thread https://mailarchive.ietf.org/arch/msg/l3sm/86TbWo1FUsKbzq9uocIv4Oh= _vfw and the following exchange mail.

 

How do you = solve this issue within the current Yang model?

 

 

From:= = stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] =
Sent: Thursday, February 25, 2016 4:24 PM
To: Aijun = Wang; l3sm@ietf.org
Subject: RE: [L3sm] Additional = Issues---site's parameter relation with specific = vpn

 

Hi,

 

Inline = comments

 

From:= L3sm [mailto:l3sm-bounces@ietf.org] = On Behalf Of Aijun Wang
Sent: Thursday, February 25, = 2016 03:34
To: l3sm@ietf.org
Subject: = [L3sm] Additional Issues---site's parameter relation with specific = vpn

 

Hi, L3SMer:

 

With the discussion about the current L3VPN yang model, we = found there is another additional issue needed to be solved. This issue = will influence the design of L3SM Yang structure as = well.

 

Issue description: In current L3VPN yang model, we define = the site’s various parameters via several = container,

such as “location”, = “site-diversity”,”management”,”vpn-policy&#= 8221;,”maximum-routes”,”security”,”service&= #8221;,”routing-protocol”,”site-network-accesses”= etc. For these containers, only the “location” is = determined and has no relation with the specific vpn id, other = containers are all related with the specific vpn = id.

That is to say, if the vpn is different, the = “site-diversity”,”management”,”vpn-policy&#= 8221;,”maximum-routes”,”security”,”service&= #8221;,”routing-protocol”,”site-network-accesses”= container will have different values, but in current Yang model, only = the “vpn-policy” has relationship with the = vpn-id.

[SLI] I cannot agree, a multiVPN scenario = strongly requires that each “VPN attachment” as the same = parameter this is by design because all the “VPN = attachments” are using the same logical access. Only the = vpn-policy plays with the VPN attachment. I think you are confusing with = subVPN where you have a logical access per VPN with potential different = parameters but this is a different subject that is also under = discussion.

 

 

Solution proposal: Put the site = definition or reference within the list “vpn-svc”, please = see https://mailarchive.ietf.org/arch/msg/l3sm/lB4HbUVczwyygAScPeh4tV0= EBRo

 

So, what your consideration for this issue and solution = proposal?

 

Best = Regards.

 =

Aijun = Wang

 =

China = Telecom Corporation Limited Beijing Research Ins= titute 

Network = Research and Operation Support Department

 

____________________________________________________________=
_____________________________________________________________<=
/span>
 
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.
------=_NextPart_000_00AC_01D16FEB.30F81F20-- From nobody Thu Feb 25 00:45:26 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9045E1A6F6E for ; Thu, 25 Feb 2016 00:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.648 X-Spam-Level: *** X-Spam-Status: No, score=3.648 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=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 ZZp16GEGe6yn for ; Thu, 25 Feb 2016 00:45:18 -0800 (PST) Received: from post-send.kddi.com (athena2.kddi.com [27.90.165.195]) by ietfa.amsl.com (Postfix) with ESMTP id DC1B11A01A3 for ; Thu, 25 Feb 2016 00:45:17 -0800 (PST) Received: from LTMC2122.kddi.com (LTMC2122.kddi.com [10.206.0.63]) by post-send.kddi.com (KDDI Mail) with ESMTP id D9737E009E; Thu, 25 Feb 2016 17:45:16 +0900 (JST) Received: from LTMC2145.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2122.kddi.com with ESMTP; Thu, 25 Feb 2016 17:45:16 +0900 Received: from LTMC2145.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id B4F653A0065; Thu, 25 Feb 2016 17:45:16 +0900 (JST) Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2145.kddi.com (Postfix) with ESMTP id A991A3A005F; Thu, 25 Feb 2016 17:45:16 +0900 (JST) Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1P8jGvJ016575; Thu, 25 Feb 2016 17:45:16 +0900 Received: from LTMC2152.kddi.com.mid_32265310 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u1P8ZFic003935; Thu, 25 Feb 2016 17:35:15 +0900 X-SA-MID: 32265310 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Thu, 25 Feb 2016 17:35:15 +0900 From: "Ogaki, Kenichi" To: "'Aijun Wang'" <13301168517@189.cn>, , References: <000101d169e8$e19802e0$a4c808a0$@kddi.com> <004901d16a02$821e7cd0$865b7670$@cn> <004101d16e97$e0692800$a13b7800$@kddi.com> <002d01d16e9f$88e66130$9ab32390$@cn> <006701d16ec0$1063fee0$312bfca0$@kddi.com> <004301d16ec8$270d9090$7528b1b0$@cn> <008401d16ede$20cee4c0$626cae40$@kddi.com> <004201d16f6f$22023cc0$6606b640$@cn> <015201d16f7c$3725b160$a5711420$@kddi.com> <008001d16f80$782b3690$6881a3b0$@cn> <018e01d16f88$3194dd50$94be97f0$@kddi.com> <009101d16f97$f8903440$e9b09cc0$@cn> <002f01d16f9d$0db35460$2919fd20$@kddi.com> <009501d16fa1$47f9b520$d7ed1f60$@cn> In-Reply-To: <009501d16fa1$47f9b520$d7ed1f60$@cn> Date: Thu, 25 Feb 2016 17:35:15 +0900 Message-ID: <004301d16fa7$738a7390$5a9f5ab0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+JsdlYZ7cvi/Fz8JTONaqj4LvoQKs2aO/AYjUCCUDWny42AHbJwT5AVTH19oBa6ZKmwJ6yFzNARuYlCYCFgz06wC+ia0/AXZZ+aECwqGYXgHD7ERHnR5cZPA= Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday L3SM interim session X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 08:45:23 -0000 Hi Aijun, See comments inline, please. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 4:51 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Please see the reply inline. -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 25, 2016 3:21 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >1. When we add one new site into one already existing vpn, we need only = add one site item within this vpn, because the item sites is one list.=20 >This is very easy via the RESTCONF api. No other contents within this = vpn will be touched. For human being, this seems trivial. But, from a system automation viewpoint, the cost to access two = different top-level containers with restconf is not ignorable, because = restconf client must access two different URIs by at least two = transactions. [Aijun Wang]: why do we need to access two different top-level = containers for adding one new site? We have put the list "sites" within = the list "vpn-svc", and it exist only once in the Yang model.=20 [KO] I may be misunderstanding. My understanding is that your proposal = only defines sites list under vpn-svc and still keeps sites container as = it is. If so, when we create one new site, we must configure sites itself and = sites list under vpn-svc. >2. If you propose the Yang structure as that described in=20 >https://mailarchive.ietf.org/arch/msg/l3sm/6zMiZSlcijda0ts_6NONdmwP3-E, = while not keep it consistence with the configuration part? You mean this cannot solve the problem? These state are not configurable and should be automatically derived = from the configuration of the sites in the current model.=20 Am I missing something? [Aijun Wang]: What I mean is that we must first define the relationship = of vpn and site(site role, site attributes etc.) first, and then reflect = it in the op-state. And you have proposed to extract the leaf = "site-role" from the "vpn-policy", why not just define it under the list = "site", and put the list "site" within the list "vpn-svc"? [KO] Yes, we must define the relationship between vpn and site, and then = reflect it to the op-state. The problem is where such relationship is defined, and I prefer it under = sites as the current model from the api viewpoint abovementioned. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 3:44 PM To: 'Ogaki, Kenichi'; 'Aijun Wang'; stephane.litkowski@orange.com; = l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: 1. When we add one new site into one already existing vpn, we need only = add one site item within this vpn, because the item sites is one list. = This is very easy via the RESTCONF api. No other contents within this = vpn will be touched. 2. If you propose the Yang structure as that described in = https://mailarchive.ietf.org/arch/msg/l3sm/6zMiZSlcijda0ts_6NONdmwP3-E, = while not keep it consistence with the configuration part? Best Regards. -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Thursday, February 25, 2016 12:52 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >[Aijun Wang]: Within current Yang model, the customer need still to=20 >configure both sites and vpn-svc. If we use the site template, some = parameters that keep unchanged need not be input by customer. I'm saying the case just adding a new site to already existing vpn. Does = this require to configure the vpn?=20 >[Aijun Wang]: If the customer does not input these information, how can = >you get it from "op-state"? The operation state should consider only = the real time information that gathered from the underlying network = dynamically. In my understanding, it's not only for real time information. I mean the = following one. https://mailarchive.ietf.org/arch/msg/l3sm/6zMiZSlcijda0ts_6NONdmwP3-E Thanks, Kenichi -----Original Message----- From: Aijun Wang [mailto:13301168517@189.cn] Sent: Thursday, February 25, 2016 12:56 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Please see the comments inline, wish we can reach an agreement before = the interim meeting. :) -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Thursday, February 25, 2016 11:26 AM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, If we configure the relationship between vpn-svc and sites as follows, = we should remove corresponding vpn-policy under sites to avoid the = inconsistency. [Aijun Wang] Yes, we should redefine the vpn-policy as = site-prefix-policy, which defines only what prefix will be advertised by = this site, not the relationship among different sites. In this case, when we create new sites, we must configure both sites and = vpn-svc, and this bothers our customers. But, the current model structure only have to configure sites. Then, I = prefer the current one. [Aijun Wang]: Within current Yang model, the customer need still to = configure both sites and vpn-svc. If we use the site template, some = parameters that keep unchanged need not be input by customer. I don't object the sites list defined under vpn-svc as a *op-state*. [Aijun Wang]: If the customer does not input these information, how can = you get it from "op-state"? The operation state should consider only = the real time information that gathered from the underlying network = dynamically. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 10:52 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Based on our discussion, do you think the following proposal are = acceptable? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } =20 list sites{ leaf site-id leaf site-role leafref path "/l3vpn-svc/site-templates/site-template-id" = =20 } } list site-templates{ ...=20 } ... } -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Wednesday, February 24, 2016 4:34 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >Within the current Yang model, it is not loose coupled for the vpn and=20 >sites. Every site is associated with at least one vpn-policy entry. I wanted to mean by loose coupling that vpn and site should be = structurally at the same level. This means that a kind of graph = structure is better than a hierarchical structure. In a VPN service, it=E2=80=99s natural that a site must belong to at = least one vpn. >The reason that I prefer the "vpn-->site" structure to "site-->vpn"=20 >structure is that the majority of containers within lists "sites" are=20 >vpn-related, as you also confirmed this. >From the configuration viewpoint in the current model, the link = information between vpn and site can be configurable only in sites. = That's vpn-policy. This is reasonable to avoid the inconsistency in the case that both can = be configurable.=20 This information, which site belongs to which vpn, may be able to be = moved under vpn-svc as a list, but I don't think the necessity. It may = be useful to define the op-state under vpn-svc as discussed in issue#6. I agreed with the principle what you wrote, but I didn't carefully = discuss each container should be under vpn-svc or site. IMO, if any container is placed inappropriately, we should just move it = to the appropriate place. It's different problem from the model = structure discussion. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 2:57 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Within the current Yang model, it is not loose coupled for the vpn and = sites. Every site is associated with at least one vpn-policy entry.=20 The reason that I prefer the "vpn-->site" structure to "site-->vpn" = structure is that the majority of containers within lists "sites" are = vpn-related, as you also confirmed this. Then it is not enough in = current Yang model to correlate only the "vpn-policy" container to = different vpn id. And on the other way, we can also use the site-template to lessen the = burden of the customer configuration, as that done in current Yang = model. -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 12:59 PM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, >1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. > >[KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. >For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. >Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. >In that sense, I basically prefer the current model. >[Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. >There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement? If a physical customer site connects to two different vpns in this case, = the customer must input or update the information about the (physical) = site duplicately per vpn-svc. This may cause misconfiguration and bother = our customers. Another concern is the inconsistency with accounting/charging model, = when an operator charges the fee for physical access, it becomes = inconsistent with the charging model. When we does a traffic accounting = not only for logical access per vpn, but also for physical access, we = must always take care of the existence of different vpn-svc with the = same physical access in order to trigger a polling traffic counter of = the interface on PE. I understand it depends on each operator's service definition, vpn = specific or site specific, as Stephane wrote. To accommodate these different requirements, I think the loose coupled = model between the components, vpn and site, seems better. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Wednesday, February 24, 2016 10:06 AM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Ogaki: Please see the reply inline. Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network = Research and Operation Support Department -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Wednesday, February 24, 2016 8:11 AM To: 'Aijun Wang'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi Aijun, See comments inline, please. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 18, 2016 1:12 PM To: 'Ogaki, Kenichi'; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Issue #10 RE: L3SM interim meeting minutes on = Thursday L3SM interim session Hi, Stephane and Ogaki: =20 I suggested we put the "extranet-vpn-policy" under the list "vpn-svc" = directly, not in the container "vpn-policy" that is now under the list = "sites" in current model.=20 [KO]Like this? container l3vpn-svc { list vpn-svc { key vpn-id; leaf vpn-id { =E2=80=A6 } ... list extranet-vpn-policy { key vpn-id; leaf vpn-id { type svc-id; } } ... } ... } [Aijun Wang]: Yes. This can solve the initial scenario that proposed by Kenichi at the = beginning of our discussion. When the orchestrator receives the = information defined in "extranet-vpn-policy", it can allocate new = route-target for the involved VPNs and set them in the configuration = stanza of each router. =20 For the relationship of list "vpn-svc" and list "sites", I still suggest = we put the list "site" under the "vpn-svc", the reason for doing this is = as below: 1. the service model must be service oriented. If one site belongs to = several vpns, we should achieve the goal by defining several service = instances. [KO] I can't agree this. The case that a site belongs to multiple vpns = is also a very common service use case, then the service model must = design this appropriately. For easy use of a service model and to avoid the misconfiguration and = inconsistency, we have to exclude duplicate configuration for the same = information, data node instance, as much as possible. Then, I proposed = to remove repetitive definitions of a vpn which can be implicitly = uniquely identified in a same transaction. But, that eventually came not = to make sense for restconf. In that sense, I basically prefer the current model. [Aijun Wang]: for sites that belong to several vpns, because we define = "vpn-svc" as list, then it can include different items, each vpn-svc = item can define its own sites coverage information. There is also no = duplicate configuration for this solution. What's the problem then for = this arrangement?=20 2. The attributes of "sites", such as "maximum-routes", "security", = "service", "routing-protocols","site-netwok-accesses" etc. are all = service/site role related, that is to say, if the site role changed, all = of these attributed may be changed accordingly. [KO] I basically agree. The attributes tied to a whole vpn and globally = applied to all the sites under the vpn should be defined with the vpn = definition. 3.For container "vpn policy" that under list "sites" in current model, = there are two information defined, one is "filter" for prefix filtering, = another is "site-role". I suggest we split it, put the leaf "site-role" = under leaf "site-id" directly, and change the name of "vpn-policy" to = "site-prefix-policy".=20 =20 The final suggest structure of the L3VPN yang model will be look like = the bellow, I underline the changed positions from the current l3vpn = Yang Model =20 Container L3vpn-svc List vpn-svc Leaf vpn-id Leaf customer-name Leaf topology List extranet-vpn-policy Container cloud-access List multicast Leaf mpls List transport-contraints =20 List sites Leaf site-id Leaf site-role leaf apply-template ... ... ... ... Container managent Container site-prefix-policy Container maximum-routes Container security ... ... ... ... Site-network-access=20 =20 =20 Whether is it more reasonable?=20 =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute=20 Network Research and Operation Support Department =20 =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, February 18, 2016 9:08 AM To: l3sm@ietf.org Subject: [L3sm] Issue #10 RE: L3SM interim meeting minutes on Thursday = L3SM interim session =20 Hi Stephane and All, =20 As for issue #10 itself, the following solution can be acceptable for = us. =20 >One proposal could be to not call this VPN policy, but creating a >container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). =20 What model is in your mind? I can't see what ""extranet-vpn-policy" at = vpn" means. Like this? =20 ... 1 VPN1 VPN2 ... =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of stephane.litkowski@orange.com = =20 Sent: Monday, December 07, 2015 11:45 PM To: Ogaki, Kenichi; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi Kenichi, =20 Regarding your proposal of having a simple VPN policy in the vpn-svc = container, I do see an issue. One of the key point of the VPN policy is = to express the role of the site in the target VPN topology. If we do a vpn policy at VPN level, we cannot anymore describe site = roles in the target VPN which causes an issue. In an ideal world where all VPNs are any to any, the site role is always = the same and there is no issue, but let's think about someone trying to = use the vpn-policy (at vpn level) to connect to a Hub & Spoke VPN, how = do you deduce the roles of the sites ? =20 One proposal could be to not call this VPN policy, but creating a = container "extranet-vpn-policy" at vpn level which will mandate an = extranet VPN architecture from a configuration point of view, deducing = automatically the appropriate RT rules to add (like creating a new pair = of RTs). This means that the usage is really limited to "simple" = extranet-vpns and it does not replace nor compete with the VPN policy at = site level. =20 Could it be a good compromise ? =20 Stephane =20 =20 -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com = ] Sent: Saturday, December 05, 2015 06:23 To: LITKOWSKI Stephane SCE/OINIS; 'Aijun Wang'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear Stephane and All, =20 I don't say that sites *must* move under vpn-svc because I understand = stephane's use case. But we already have vpn-svc and some parameters under this are globally = applied to all the sites even in the current model. =20 It depends on operator's use case which is site-oriented or vpn-oriented = service. Our service is vpn-oriented, site has the native VPN. Then, I would just = like you to allow other global options to vpn-svc. =20 Thanks, Kenichi =20 -----Original Message----- From: stephane.litkowski@orange.com = = [mailto:stephane.litkowski@orange.com = ] Sent: Friday, December 04, 2015 8:17 PM To: Aijun Wang; 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org = =20 Cc: adrian@olddog.co.uk =20 Subject: RE: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Hi, =20 I'm against this proposal, as I do not want to create any dependency = between a particular VPN and a list of sites. A site can belong to multiple VPNs with any kind of topology, if we = attach the site to a single VPN, we come back to the notion of "native = VPN" we had at the beginning of the model which was hard to understand = and so was removed. =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Aijun Wang Sent: Friday, December 04, 2015 02:44 To: 'Ogaki, Kenichi'; 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear all: =20 Can we put the list "sites" within the list "vpn-svc", and define the = general vpn policy for all sites that within the corresponding vpn = service instance? If doing so, some entries within the current list "sites" can also be = dragged out for general usual purposes, for example, "maximum-routes", = "security" etc. These parameters are often all same for every site = within one VPN service instance.=20 =20 If some sites have special requirements, we can achieve this by using = some special "site-vpn-policy" within the corresponding site definition. Is this more acceptable for customers? =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute Intelligent = Network Product Line =20 =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Ogaki, Kenichi Sent: Friday, December 04, 2015 9:02 AM To: 'Qin Wu'; l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: Re: [L3sm] L3SM interim meeting minutes on Thursday L3SM = interim session =20 Dear All, =20 It was good having discussion. =20 As for issue#10, the objective and problem we discussed in the meeting = as follows. =20 The objective is to provide per-VPN extranet service which connects two = different VPNs (e.g. VPN1 and VPN2). It means that any sites in VPN1 can = access to any sites in VPN2. The problem is that the current model must update vpn-policy under all = the sites belong to these two VPNs in order to offer this service. = Especially when this model is used as a customer self-control API, it's = not good idea to require customers to update the information of all the = sites. (It's not abstracted way, a service model should provide what the = consumer wants, not how.) If a service or customer requires to control = per-site vpn-policy, that of current model should be used without = setting per-VPN vpn-polity. It depends on each operator's service. Stephane proposed to use apply-template, but it still cannot solve the = problem. When each VPN already has a large number of sites and want to = connect each other for the first time, both VPNs must update these sites = to apply apply-template on the current model. =20 Thanks, Kenichi =20 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org = ] On Behalf Of Qin Wu Sent: Friday, December 04, 2015 12:42 AM To: l3sm@ietf.org =20 Cc: adrian@olddog.co.uk =20 Subject: [L3sm] L3SM interim meeting minutes on Thursday L3SM interim = session =20 Hi all: =20 =20 Below is the initial version of draft minutes for Thursday L3SM WG = interim session. =20 Thanks Dan to help take minutes. =20 Folks, please let us know if you have any correction. =20 =20 -Qin =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =20 L3SM Working Group Virtual Interim Meeting=20 =20 Thursday December 5th, 2015. 8am East Coast Time (New York) =20 =20 BLUE SHEET =20 =20 Name | Affiliation =20 ------------------------+----------------------------------------------- ------------------------+- =20 Adrian Farrel | Old Dog Consulting =20 Qin Wu | Huawei Technologies =20 Stephane Litkowski | Orange =20 Luis Tomotaki | Verizon =20 Daniel King | Old Dog Consulting =20 Susan Hares | Huawei Technologies =20 Scott Mansfield | Ericsson =20 Gu Rong | China Mobile=20 =20 Kenichi Ogaki | KDDI =20 Aijun Wang | China Telecom =20 Victor Santos | Ericsson =20 Ignas Bagdonas |=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 MINUTES =20 =20 * Meting logiistics = https://mailarchive.ietf.org/arch/msg/l3sm/SJub1aHVQGOQW6rWhthX0fB8Ac8 = = =20 =20 * Meeting materials = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/proceedings.html= = =20 =20 * Etherpad for minutes (this page) = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03 = =20 =20 * Jabber using l3sm@jabber.ietf.org =20 =20 * Blue sheet = http://etherpad.tools.ietf.org:9000/p/l3sm-interim-2015-12-03-bluesheet = = =20 =20 =20 Agendaa =20 - Administrivia (Note Well, etc). a =20 - Introduction =20 - Open Issues for YANG Data Model for L3VPNservice delivery = (draft-ietf-l3sm-l3vpn-servicemodel) =20 o Open Issues discussion and resolution=E2=80=93 = http://trac.tools.ietf.org/wg/l3sm/trac/report/1 = =20 =20 =20 For a full list of issues and resolution proposals please see: = https://www.ietf.org/proceedings/interim/2015/12/03/l3sm/slides/slides-in= terim-2015-l3sm-1-2.pdf = =20 =20 =20 Issue#1: When customer-nat-address is used =20 Resolution #1: Leaf used when NAT is required to access cloud VPN and = customer wants to use its ownIP address. If provider provides the public = IP,no need to use the leaf =20 Status #1: Closed Pending I-D text review. =20 =20 Discussion on #1:=20 =20 =20 Aijun asks for more description in the YANG model itself =20 Stephane shows current model =20 Agreed OK =20 =20 Issue#2 : Identify l3vpn svc using id or name or both =20 Resolution #2: ID is a string, as per other properties in the model =20 Status #2: Closed =20 Discussion on #2:=20 =20 =20 Agreed OK =20 =20 Issue#3: M to N availability support =20 Resolution #3: Modeling sites using a list with a priority, so include = access list with a priority. =20 Status #3: =20 Discussion on #3:=20 =20 =20 Qin was asking that M to N availability is supported with access and = priority number.=20 =20 Stephane stated this is suppoted. This new proposal also supports = multiple sites, as a list. =20 Qin also asked if Group I-D was no longer needed, which it is not. Also = good solution supported by other operators. =20 Stephane asked if four priorities was enough, or if more were needed.=20 =20 =20 Re: Containers/Properties for Network Access Configuration - = Conclusions? =20 =20 o Location - Different site I-D? =20 o QoS Policy - Per network access link, or site information? Would QoS = (cost) be different per accesslink or site? Example of Primary and = Backup links given.=20 =20 o Bandwidth - Moved to access link group=20 =20 o Maximum Routes -=20 =20 Security, routing, and services are duplicated with inheritance =20 =20 =20 Issue#4: site-service-cloud access as grouping =20 Resolution #4 Already resilved as a separate grouping =20 Status #4: Closed =20 Discussion on #4:=20 =20 =20 Issue#5: Multicast support as raised by Eric Rosen =20 Resolution #5: : New "provider managed" property, and in Site Properties = "property-type" added =20 Status #5: Solution proposed.=20 =20 Discussion on #5:=20 =20 =20 Stephane will proviode new property proposals will be provided to Eric = for review.=20 =20 =20 Issue#6: Inventory operational state =20 Resolution #6: Include a new container for inventory state, or an RPC = call (sitting above the service orchestrator) to retrieve inventory = state.=20 =20 Status #6: Need to propose to the WG and agree solution. =20 Discussion on #6:=20 =20 =20 Luis asked would this info be collected from provision state? Stephane = suggested this would not be availible.=20 =20 Adrian observed that the code used to convert the model into a service = request may not utilise this inventory information capability. Sue = mentioned that others have mentioned by a vendor that it would be useful = to have the ability to configure inventory state. This should be = clarified by the operators.=20 =20 =20 Stephane to take proposals to list and ask anyone who is interested in = having the feature to suggest text. =20 =20 =20 Issue#7: Generic VAS - do we need to create a generic VAS container as = VAS are popular in L3VPNs? =20 Resolution #7: Separate from L3SM =20 Status #7: Closed =20 Discussion on #7:=20 =20 =20 Gu Rong highlighted Generic VAS model which was presented at IETF 94.=20 =20 =20 Issue#8: Who keeps site locationinformation? =20 Resolution #8: Text has been fixed =20 Status #8: Closed =20 Discussion on #8:=20 =20 =20 =20 Issue#9: Do we need to model transport constraints, such as: jitter, = disjoint, path diversity? =20 Resolution #9: Propose a "transport-constraint" group with = "constraint-type", "constraint-value" and "constraint-list" (composed of = type and values) =20 Status #9: Authors to propose the resolution in the I-D and provide to = the WG =20 Discussion on #9: =20 =20 =20 =20 Luis mentioned that they have multicast transport (multiple sites) and = bi-directional traffic applications (financial) that will require = transport constraints =20 =20 Duplicate transport constraints for unicast and multicast to give = options for separate configuration. =20 Keep single list entries for each src/dst pair even in the multicast = variant. =20 =20 DO we need to support multiple constraints or just have a single = composite (of multiple constraints), have the ability to specify a = constraint-list? =20 Aijun prfers list of constraints and meeting agrees this is OK =20 =20 What constraints to offer? =20 Latency =20 Path diversty =20 Site diversty =20 Jitter =20 Class of service was proposed but rejected =20 =20 Luis highlighted they have a current implementation that uses the = similar proposal. Luis also mentioned that site diversity might also be = required, would this be achievable =20 =20 =20 Issue#10: VPN "merging" =20 Resolution #10: =20 =20 Status #10: =20 Discussion on #10: =20 =20 =20 VPN is a per site property.=20 =20 - A site can belong tomultiple VPNs =20 - How to handle merging of two VPNs? =20 - Is this an issue the service model has to deal with? =20 =20 If VPN merging is required to be seamless, then this would be device = specific and not service model related. =20 =20 =20 "Merging" is a confusing term. The objective is NOT to merge VPN1 and = VPN2. =20 The objective is to provide an extranet so that some sites in VPN1 can = connect to some sites in VPN2 for some traffic. =20 This can be solved using a per-site property. =20 =20 Action: Need to update this issue to make it clear what function was = being discussed, also Stephane will send options to the working group- = list.=20 =20 We are specifically looking for people who offer extranet connection = between sites from different VPNs =20 =20 =3D=3D Other Issues =3D=3D =20 =20 =20 Modeling Customer Specific Info =20 - Create appropiate containers for Provider Edge and Customer Site = routers =20 - The current model contains routing parametres that refer to CE and PE = relationships =20 - General agreement is routing info should be split and current proposal = will be sent to the list for Kenichi, and working groups, review.=20 =20 =20 =3D=3D Conclusions =3D=3D =20 =20 - A number of resolutions have been agreed and will be updated in the = I-D =20 - Chairs would like to see revised I-D based on the agreed points =20 - Plan to have another interim call at the end of January (2016) =20 - Chairs to add new tracker items, including security for future = discussion.=20 =20 =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 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, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci =20 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 authorization. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if = this message was modified, changed or falsified. Thank you. =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 =20 _______________________________________________ L3sm mailing list L3sm@ietf.org =20 https://www.ietf.org/mailman/listinfo/l3sm = =20 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Thu Feb 25 00:48:28 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787BA1A6FBE for ; Thu, 25 Feb 2016 00:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 542aTCcsvP0M for ; Thu, 25 Feb 2016 00:48:23 -0800 (PST) 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 BF47E1A6FB9 for ; Thu, 25 Feb 2016 00:48:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEZ17068; Thu, 25 Feb 2016 08:48:17 +0000 (GMT) Received: from LHREML702-CAH.china.huawei.com (10.201.5.99) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 08:47:52 +0000 Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 08:47:51 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 16:47:46 +0800 From: Qin Wu To: "Ogaki, Kenichi" , "stephane.litkowski@orange.com" , "l3sm@ietf.org" Thread-Topic: [L3sm] Modeling a site with multiple subsites Thread-Index: AdFPnqCmtWfFPEtQT6m/5Yx5kcaoDABqSt8AABDyLYAAJeSogAar8U0AAKsvQfD//4regP//O49A Date: Thu, 25 Feb 2016 08:47:46 +0000 Message-ID: References: <11137_1452868271_569902AF_11137_18933_1_9E32478DFA9976438E7A22F69B08FF921683F2D0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <009a01d1518a$dccd16e0$966744a0$@kddi.com> <28946_1453107612_569CA99C_28946_1310_1_9E32478DFA9976438E7A22F69B08FF921683F60F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <000001d15266$38428380$a8c78a80$@kddi.com> <002c01d16d15$fb50c390$f1f24ab0$@kddi.com> <018d01d16f88$2776fd80$7664f880$@kddi.com> In-Reply-To: <018d01d16f88$2776fd80$7664f880$@kddi.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.208] 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.56CEBFD2.0123, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0fc334dc862f576fa83551b6ce03c7ca Archived-At: Subject: Re: [L3sm] Modeling a site with multiple subsites X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 08:48:27 -0000 SWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCBpbiB0aGUgbXVsdGktaG9taW5nIGNhc2Us IHdlIGNhbiB1c2UgTEFOIHByZWZpeCBpbiBWUE4tcG9saWN5IHRvIGJpbmQgZWFjaCBMQU4gdG8g ZGlmZmVyZW50IFZQTnMsIHdoaWNoIGFsbG93IHVzIGNvbm5lY3Qgb25lIHNpdGUgdG8gbXVsdGlw bGUgVlBOcywNCkJ1dCBJIGFtIG5vdCBzdXJlIGhvdyB0byBiaW5kIExBTiBwcmVmaXggdGhyb3Vn aCBzcGVjaWZpYyBuZXR3b3JrIGFjY2VzcyB0byBvbmUgc3BlY2lmaWMgVlBOLCBkbyB3ZSBoYXZl IG1lY2hhbmlzbSB0byBzdXBwb3J0IHRoaXM/IEJHUD8NCg0KQnkgZGVmaW5pbmcgVlBOIHBvbGlj eSB1bmRlciBuZXR3b3JrIGFjY2VzcywgaXQgc2VlbXMgdG8gbWVhbiBvbmUgbmV0d29yayBhY2Nl c3Mgc2hvdWxkIGJlIGFzc29jaWF0ZWQgd2l0aCBvbmUgb3IgbXVsdGlwbGUgTEFOIHByZWZpeCwg d2hlbiB0aGVyZSBpcyBhIHJvdXRlIHRoYXQgbmVlZCB0byBiZSBkaXN0cmlidXRlZCB0byBzcGVj aWZpYyBMQU4sIGl0IHNob3VsZCBiZSBkaXN0cmlidXRlZCB0byB0aGUgc3BlY2lmaWMgTEFOIHRo cm91Z2ggc3BlY2lmaWMgbmV0d29yayBhY2Nlc3M/IFdyb25nPw0KDQotUWluDQotLS0tLdPKvP7U rbz+LS0tLS0NCreivP7IyzogT2dha2ksIEtlbmljaGkgW21haWx0bzprZS1vb2dha2lAa2RkaS5j b21dIA0Kt6LLzcqxvOQ6IDIwMTbE6jLUwjI1yNUgMTI6NTENCsrVvP7IyzogUWluIFd1OyBzdGVw aGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBpZXRmLm9yZw0K1vfM4jogUkU6IFtMM3Nt XSBNb2RlbGluZyBhIHNpdGUgd2l0aCBtdWx0aXBsZSBzdWJzaXRlcw0KDQpIaSBRaW4sDQoNCj5T dXBwb3J0IHN1YlZQTiBjYXNlIG9yIG11bHRpcGxlIG5ldHdvcmsgYWNjZXNzZXMgdGhhdCBpcyBu b3QgZm9yIG11bHRpaG9taW5nPw0KDQpOb3QgZm9yIG11bHRpaG9taW5nIGZyb20gYSBzaXRlIHRv IGEgc2luZ2xlIFZQTihvciB1bmRlciBhIHNpbmdsZSB2cG4tcG9saWN5KS4NClRoZSBjdXJyZW50 IG1vZGVsIGNhbiBvbmx5IGRpZmZlcmVudGlhdGUgdnBuLXBvbGljeSBwZXIgc2l0ZXMuIEJ1dCwg dGhlcmUgYXJlIG1hbnkgdXNlIGNhc2VzIHRvIHJlcXVpcmUgdnBuLXBvbGljeSBwZXIgc2l0ZS1u ZXR3b3JrLWFjY2Vzcy4NCllvdSBjYW4gZmluZCB0aGUgY3VycmVudCBsaW1pdGF0aW9uIGFuZCB1 c2UgY2FzZXMgb24gdGhlIGV4Y2hhbmdlcyBpbiB0aGlzIHRocmVhZC4NCg0KPkkgYmVsaWV2ZSB0 aGlzIGlzc3VlIGlzIHNlcGFyYXRlZCBmcm9tIHdoYXQgd2UgZGlzY3Vzc2VkIGVhcmxpZXIgYWJv dXQgZXh0cmFuZXQgVlBOIHBvbGljeS4NClllcywgdGhpcyBpcyBkaWZmZXJlbnQgaXNzdWUuDQoN ClRoYW5rcywNCktlbmljaGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEwz c20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBRaW4gV3UNClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNSwgMjAxNiAxMjo1NyBQTQ0KVG86IE9nYWtpLCBLZW5p Y2hpOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtMM3NtXSBNb2RlbGluZyBhIHNpdGUgd2l0aCBtdWx0aXBsZSBzdWJzaXRlcw0KDQpL ZW5pY2hpOg0KQ2FuIHlvdSBjbGFyaWZ5IGEgbGl0dGxlIGJpdCB0aGUgb2JqZWN0aXZlIG9mIHRo ZSBmb2xsb3dpbmcgcHJvcG9zYWw/DQpTdXBwb3J0IHN1YlZQTiBjYXNlIG9yIG11bHRpcGxlIG5l dHdvcmsgYWNjZXNzZXMgdGhhdCBpcyBub3QgZm9yIG11bHRpaG9taW5nPw0KSSBiZWxpZXZlIHRo aXMgaXNzdWUgaXMgc2VwYXJhdGVkIGZyb20gd2hhdCB3ZSBkaXNjdXNzZWQgZWFybGllciBhYm91 dCBleHRyYW5ldCBWUE4gcG9saWN5Lg0KDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7I yzogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBPZ2FraSwgS2VuaWNo aQ0Kt6LLzcqxvOQ6IDIwMTbE6jLUwjIyyNUgMTA6MDkNCsrVvP7Iyzogc3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5vcmcNCtb3zOI6IFJlOiBbTDNzbV0gTW9kZWxpbmcg YSBzaXRlIHdpdGggbXVsdGlwbGUgc3Vic2l0ZXMNCg0KSGkgU3RlcGhhbmUgYW5kIEFsbCwNCg0K Pj5Ib3cgdG8geW91IGRpZmZlcmVudGlhdGUgbXVsdGlob21pbmcgZnJvbSB5b3VyIHN1YlZQTiBj YXNlPyB0aGV5IGFyZSANCj4+dHdvIGRpZmZlcmVudA0KPnRoaW5ncy4NCg0KPkFzIEkgd3JvdGUs IHdlIGp1c3QgaGF2ZSB0byAqZHVwbGljYXRlKiB2cG4tcG9saWN5IHVuZGVyIA0KPnNpdGUtbmV0 d29yay1hY2Nlc3MuIFdoZW4gYW4gb3BlcmF0b3IncyB1c2UgY2FzZSByZXF1aXJlcyBtdWx0aVZQ TiwgDQo+dGhlbiB2cG4tcG9saWN5IHNob3VsZCBiZSB1bmRlciBzaXRlcyBhcyB0aGUgY3VycmVu dCBtb2RlbCBkb2VzLg0KPldoZW4gdGhlIG90aGVyIG9wZXJhdG9yIHJlcXVpcmVzIHN1YlZQTiwg dnBuLXBvbGljeSBzaG91bGQganVzdCBiZSANCj51bmRlciBzaXRlLSBuZXR3b3JrLWFjY2Vzcy4g SXQncyBzdWZmaWNpZW50IHRvIHVzZSB0aGVzZSB0d28gY2FzZXMgZXhjbHVzaXZlbHkuDQoNCkhl cmUgaXMgYSBtaW5pbXVtIG1vZGlmaWNhdGlvbiBwcm9wb3NhbCB0byB0aGUgY3VycmVudCBtb2Rl bCBpbiBvcmRlciB0byB1c2UgdGhlc2UgdHdvIGNhc2VzIGV4Y2x1c2l2ZWx5Lg0KT25seSBpZiBh IHZwbi1wb2xpY3kgaXMgbm90IGRlZmluZWQgZGlyZWN0bHkgdW5kZXIgc2l0ZXMsIHdlIGNhbiBk ZWZpbmUgaXQgdW5kZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzcy4NCklmIHNvbWV0aGluZyBpcyBncmFt bWF0aWNhbGx5IHdyb25nIGluIHRlcm1zIG9mIFlBTkcgYW5kIFhQQVRIIGV4cHJlc3Npb24sIGNv dWxkIGFueW9uZSBjb3JyZWN0IG1lPw0KDQouLi4NCmNvbnRhaW5lciBzaXRlLW5ldHdvcmstYWNj ZXNzZXMgew0KICAgIGxpc3Qgc2l0ZS1uZXR3b3JrLWFjY2VzcyB7DQogICAgICAgIHVzZXMgc2l0 ZS12cG4tcG9saWN5IHsNCiAgICAgICAgICAgIHJlZmluZSB2cG4tcG9saWN5IHsNCiAgICAgICAg ICAgICAgICB3aGVuICJub3QoLi4vLi4vLi4vdnBuLXBvbGljeSkiOw0KICAgICAgICAgICAgfQ0K ICAgICAgICB9DQogICAgLi4uDQogICAgfQ0KLi4uDQp9DQouLi4NCg0KVGhhbmtzLA0KS2VuaWNo aQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE9nYWtpLCBLZW5pY2hpDQpTZW50OiBUdWVz ZGF5LCBKYW51YXJ5IDE5LCAyMDE2IDEyOjA1IFBNDQpUbzogc3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb207IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTDNzbV0gTW9kZWxpbmcgYSBz aXRlIHdpdGggbXVsdGlwbGUgc3Vic2l0ZXMNCg0KSGkgU3RlcGhhbmUsDQoNCj5XZSBjYW5ub3Qg dXNlIHNpdGUtbmV0d29yay1hY2Nlc3Mgd2hpY2ggaXMgdXNlZCBmb3IgbXVsdGlob21pbmcgb25s eS4NCg0KV2h5IGRvIHdlIGhhdmUgdG8gdXNlIHNpdGUtbmV0d29yay1hY2Nlc3Mgb25seSBmb3Ig bXVsdGlob21pbmc/IFRoaXMgaXMgaW50dWl0aXZlbHkgbWFwcGVkIHRvIGEgbG9naWNhbCBhY2Nl c3MgYXMgeW91IHdyb3RlLg0KDQoNCj5Ib3cgdG8geW91IGRpZmZlcmVudGlhdGUgbXVsdGlob21p bmcgZnJvbSB5b3VyIHN1YlZQTiBjYXNlPyB0aGV5IGFyZSB0d28gZGlmZmVyZW50IHRoaW5ncy4N Cg0KQXMgSSB3cm90ZSwgd2UganVzdCBoYXZlIHRvICpkdXBsaWNhdGUqIHZwbi1wb2xpY3kgdW5k ZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzcy4gV2hlbiBhbiBvcGVyYXRvcidzIHVzZSBjYXNlIHJlcXVp cmVzIG11bHRpVlBOLCB0aGVuIHZwbi1wb2xpY3kgc2hvdWxkIGJlIHVuZGVyIHNpdGVzIGFzIHRo ZSBjdXJyZW50IG1vZGVsIGRvZXMuDQpXaGVuIHRoZSBvdGhlciBvcGVyYXRvciByZXF1aXJlcyBz dWJWUE4sIHZwbi1wb2xpY3kgc2hvdWxkIGp1c3QgYmUgdW5kZXIgc2l0ZS1uZXR3b3JrLWFjY2Vz cy4gSXQncyBzdWZmaWNpZW50IHRvIHVzZSB0aGVzZSB0d28gY2FzZXMgZXhjbHVzaXZlbHkuDQoN Cg0KPkNvdWxkIHlvdSBwcm92aWRlIG1vcmUgdGVjaG5pY2FsIGRldGFpbCBzbyBJIHdpbGwgYmUg YWJsZSB0byB1bmRlcnN0YW5kIHdoYXQgZXhhY3RseSB5b3UgYXJlIHRyeWluZyB0byBhY2hpZXZl ID8NCg0KT3VyIGV4aXN0aW5nIGNvbW1lcmNpYWwgc2VydmljZSBhbGxvd3MgdGhlICpsb2dpY2Fs bHkqIGZvbGxvd2luZyBkaWFncmFtLg0KUEUxLCBQRTIgYW5kIFBFMyBjYW4gYmUgVlJGcyBpbnNp ZGUgYSBzaW5nbGUgcGh5c2ljYWwgUEUsIG9yIG1heSBiZSBwaHlzaWNhbGx5IHNlcGFyYXRlIFBF cy4gU2FtZSBhcyBDRXMuIEwyU1cgY2FuIGJlIFFpblEgc3ViLWludGVyZmFjZXMgb24gYSBzaW5n bGUgcGh5c2ljYWwgUEUgZGVwZW5kaW5nIG9uIHRoZSBhYm92ZSBjYXNlLg0KDQpUaGVuLCB3ZSBt YXkgbWFwIGVhY2ggZWxlbWVudCBsaWtlIHRoaXMuDQoNCnNpdGVzOiBBIGN1c3RvbWVyIHByZW1p c2VzIGNvbm5lY3RlZCB2aWEgUWluUSAoc3RhZyAxMDApDQpzdWItc2l0ZXM6IEEgY3VzdG9tZXIg cHJlbWlzZXMnIGxheWVyIDIgc2VnbWVudCBzZXBhcmF0ZWQgYnkgLjFRIChjdGFnIDEwIG9yIDIw KSwgYSBjdGFnIHNlZ21lbnQgY2FuIGluY2x1ZGUgbXVsdGlwbGUgbG9naWNhbCBhY2Nlc3NlcyB3 aXRoIGJncCBwZWVyIHBlciBsb2dpY2FsIGFjY2Vzcy4gRm9yIGV4YW1wbGUsIFBFMSBoYXMgYSBi Z3AgcGVlciB3aXRoIENFMSwgYW5kIFBFMiBoYXMgYSBkaWZmZXJlbnQgYmdwIHBlZXIgd2l0aCBD RTIuDQoNCkluIHRoaXMgY2FzZSwgd2hlbiBWUE4gWCBvbmx5IHRhbGtzIHRvIExBTiBYLCB3ZSBu ZWVkIHN1YlZQTiBpbnNpZGUgc3ViLXNpdGVzLiBCdXQsIHdlIGNhbiBkZWFsIHdpdGggYSBzdWIt c2l0ZXMgYXMgYSBzaXRlcyBmb3IgdGhlIHNpbXBsaWNpdHkgdG8gbWluaW1hbGx5IGV4dGVuZCB0 aGUgY3VycmVudCBtb2RlbC4gRXZlbiBzbywgd2Ugc3RpbGwgbmVlZCB2cG4tcG9saWN5IHBlciBz aXRlLW5ldHdvcmstYWNjZXNzLg0KDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCnwg ICAgICAgIC8tLS1cIGN0YWcgMTAgICAgICAgIHwgICAgICAgIHwgICAgICAgIGN0YWcgMTAgLy0t LVwgICAgICAgICB8DQp8IFZQTiBBLSsgUEUxICstLS0tLS0tLSsgICAgICB8ICAgICAgICB8ICAg ICAgKy0tLS0tLS0tKyBDRTEgKy1MQU4gQSAgfA0KfCAgICAgICAgXC0tLS8gICAgICAgICB8ICAg ICAgfCAgICAgICAgfCAgICAgIHwgICAgICAgICBcLS0tLyAgICAgICAgIHwNCnwgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgIHwgICAgICAgIHwgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICB8DQp8ICAgICAgICAvLS0tXGN0YWcgMTArLSstLS0tKyB8c3RhZyAxMDB8ICstLS0tKy0rY3Rh ZyAxMC8tLS1cICAgICAgICAgfA0KfCBWUE4gQi0rIFBFMiArLS0tLS0tKyBMMlNXICstKy0tLS0t LS0tKy0rIEwyU1cgKy0tLS0tLSsgQ0UyICstTEFOIEIgIHwNCnwgICAgICAgIFwtLS0vICAgICAg ICstKy0tLS0rIHwgICAgICAgIHwgKy0tLS0rLSsgICAgICAgXC0tLS8gICAgICAgICB8DQp8ICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgfA0KfCAgICAgICAgLy0tLVxjdGFnIDIwICB8ICAgICAgfCAgICAgICAgfCAgICAg IHwgY3RhZyAyMCAvLS0tXCAgICAgICAgIHwNCnwgVlBOIEMtKyBQRTMgKy0tLS0tLS0tKyAgICAg IHwgICAgICAgIHwgICAgICArLS0tLS0tLS0rIENFMyArLUxBTiBDICB8DQp8ICAgICAgICBcLS0t LyAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgIFwtLS0vICAgICAgICAg fA0KfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICBDZW50cmFsIE9mZmlj ZSAgICAgICAgICAgICAgICAgICAgICAgIEN1c3RvbWVyIFByZW1pc2VzDQoNCkFsbCB0aGUgYmVz dCwNCktlbmljaGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEwzc20gW21h aWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBzdGVwaGFuZS5saXRrb3dz a2lAb3JhbmdlLmNvbQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDE4LCAyMDE2IDY6MDAgUE0NClRv OiBPZ2FraSwgS2VuaWNoaTsgbDNzbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtMM3NtXSBNb2Rl bGluZyBhIHNpdGUgd2l0aCBtdWx0aXBsZSBzdWJzaXRlcw0KDQpIaSwNCg0KV2UgY2Fubm90IHVz ZSBzaXRlLW5ldHdvcmstYWNjZXNzIHdoaWNoIGlzIHVzZWQgZm9yIG11bHRpaG9taW5nIG9ubHku DQpIb3cgdG8geW91IGRpZmZlcmVudGlhdGUgbXVsdGlob21pbmcgZnJvbSB5b3VyIHN1YlZQTiBj YXNlID8gdGhleSBhcmUgdHdvIGRpZmZlcmVudCB0aGluZ3MuDQpTbyBJJ20gY29tcGxldGVseSBh Z2FpbnN0IHVzaW5nIHNpdGUtbmV0d29yay1hY2Nlc3NlcyBhcyBhIHN1YlZQTiBjYW4gYmUgYWxz byBtdWx0aWhvbWVkIC4uLg0KDQo+IEZZSSwgb3VyIGNvbW1lcmNpYWwgc2VydmljZSBob25lc3Rs eSBoYXMgYSBzaW1pbGFyIGVsZW1lbnQgYXMgc3ViLXNpdGVzLCBjb3JyZXNwb25kaW5nIHRvIHZs YW4sIGJ1dCB3ZSBzdGlsbCBhbGxvd3MgbXVsdGlwbGUgdnBucyBhbmQgYmdwIHBlZXJzLCBlYWNo IGRpZmZlcmVudCB2cG4gYWNjZXNzIHBlciBwZWVyLCB3aXRoaW4gYSBzaW5nbGUgdmxhbi4NCkNv dWxkIHlvdSBwcm92aWRlIG1vcmUgdGVjaG5pY2FsIGRldGFpbCBzbyBJIHdpbGwgYmUgYWJsZSB0 byB1bmRlcnN0YW5kIHdoYXQgZXhhY3RseSB5b3UgYXJlIHRyeWluZyB0byBhY2hpZXZlID8NCg0K QmVzdCBSZWdhcmRzLA0KDQpTdGVwaGFuZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBPZ2FraSwgS2VuaWNoaSBbbWFpbHRvOmtlLW9vZ2FraUBrZGRpLmNvbV0NClNlbnQ6 IE1vbmRheSwgSmFudWFyeSAxOCwgMjAxNiAwMTo1NQ0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBT Q0UvT0lOSVM7IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbTDNzbV0gTW9kZWxpbmcgYSBz aXRlIHdpdGggbXVsdGlwbGUgc3Vic2l0ZXMNCg0KSGkgU3RlcGhhbmUsDQoNCj5TaW5nbGUgInBo eXNpY2FsIiBhY2Nlc3MgYmV0d2VlbiBTUCBhbmQgY3VzdG9tZXIsIGJ1dCBtdWx0aXBsZSBzdWIt YWNjZXNzZXMgb24gdG9wIChWTEFOLCBQUFAgc2Vzc2lvbnMsIG9yIHdoYXRldmVyIC4uLiksIGVh Y2ggb25lIHBvaW50aW5nIHRvIGEgc3BlY2lmaWMgVlBOLg0KDQpBcyB5b3Ugd3JvdGUgYWJvdmUg aW4gdGhlIHNjZW5hcmlvIGEpIGFuZCBiKSwgdnBuLXBvbGljeSBvbmx5IGhhdmUgdG8gYmUgY29u dHJvbGxlZCBwZXIgbG9naWNhbCBhY2Nlc3MsIGVxdWl2YWxlbnQgdG8gdGhlIHNpdGUtbmV0d29y ay1hY2Nlc3MgaW4gdGhlIGN1cnJlbnQgbW9kZWwuIFRvIHNvbHZlIHRoZSBpc3N1ZSBhcyBzaW1w bGUgYXMgcG9zc2libGUsIGl0J3Mgc3VmZmljaWVudCB0byBkdXBsaWNhdGUgdnBuLXBvbGljeSB1 bmRlciBzaXRlLW5ldHdvcmstYWNjZXNzLg0KSW4gdGhlc2UgY2FzZXMsIGEgY29tcGxldGVseSBk aWZmZXJlbnQgY29uY2VwdHVhbCBlbGVtZW50LCBzdWItc2l0ZXMsIGlzIG5vdCByZXF1aXJlZC4g VGhpcyBtdXN0IGJyaW5nIGEgY29tcGxleGl0eSwgYW5kIHNvbWV0aW1lcyBoYXJkIHRvIGJlIHVu ZGVyc3Rvb2QsIGRlcGVuZGluZyBvbiBvcGVyYXRvcidzIHVzZWNhc2UuIA0KQWx0aG91Z2ggd2Ug c2hvdWxkbid0IGRpc2N1c3MgdGhlIGRldmljZSBtb2RlbGxpbmcsIHRoZSBncmFudWxhcml0eSBv ZiBzdWItc2l0ZXMgY29ycmVzcG9uZHMgdG8gYSBWUkYncyBvbmUgZnJvbSB0aGUgdmlld3BvaW50 IG9mIHZwbi1wb2xpY3kuIEluIHRoaXMgY2FzZSwgbm9ib2R5IGludHVpdGl2ZWx5IGltYWdpbmVz IChzdWItKXNpdGVzIGZyb20gVlJGLCBiZWNhdXNlIGl0J3MgY29tbW9ubHkgaW4gYSBzaW5nbGUg cGh5c2ljYWwgYm94Lg0KDQpGWUksIG91ciBjb21tZXJjaWFsIHNlcnZpY2UgaG9uZXN0bHkgaGFz IGEgc2ltaWxhciBlbGVtZW50IGFzIHN1Yi1zaXRlcywgY29ycmVzcG9uZGluZyB0byB2bGFuLCBi dXQgd2Ugc3RpbGwgYWxsb3dzIG11bHRpcGxlIHZwbnMgYW5kIGJncCBwZWVycywgZWFjaCBkaWZm ZXJlbnQgdnBuIGFjY2VzcyBwZXIgcGVlciwgd2l0aGluIGEgc2luZ2xlIHZsYW4uDQoNCkFsbCB0 aGUgYmVzdCwNCktlbmljaGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEwz c20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBzdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbQ0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDE1LCAyMDE2IDExOjMx IFBNDQpUbzogbDNzbUBpZXRmLm9yZw0KU3ViamVjdDogW0wzc21dIE1vZGVsaW5nIGEgc2l0ZSB3 aXRoIG11bHRpcGxlIHN1YnNpdGVzDQoNCltDcmVhdGluZyBhbm90aGVyIHRvcGljIGZvciBiZXR0 ZXIgZm9sbG93dXBdDQoNCiANCg0KVG9kYXkgdGhlIG1vZGVsIGhhcyB0aGUgYWJpbGl0eSB0byBj cmVhdGUgc2l0ZXMsIGEgc2l0ZSBjYW4gYmUgbXVsdGlob21lZCB0byB0aGUgbmV0d29yayB0aGFu a3MgdG8gdGhlIHNpdGUtbmV0d29yay1hY2Nlc3Mgc3ViLXRyZWUuDQoNCiANCg0KTm93IHRoZSBx dWVzdGlvbiBpcyBob3cgdG8gd2UgbW9kZWwgc3VjaCBzY2VuYXJpb3MgOg0KDQogDQoNCmEpICAg ICAgIlNVQlZQTiBjYXNlIiA6IFNpbmdsZSAicGh5c2ljYWwiIGFjY2VzcyBiZXR3ZWVuIFNQIGFu ZCBjdXN0b21lciwgYnV0IG11bHRpcGxlIHN1Yi1hY2Nlc3NlcyBvbiB0b3AgKFZMQU4sIFBQUCBz ZXNzaW9ucywgb3Igd2hhdGV2ZXIgLiksIGVhY2ggb25lIHBvaW50aW5nIHRvIGEgc3BlY2lmaWMg VlBOLiBJdCBpcyBleHBlY3RlZCBmb3IgdGhlIGN1c3RvbWVyIHRvIGVuc3VyZSBmbG93IHNlcGFy YXRpb24gKFZSRiBsaXRlLCBWTEFOcyAuKS4gSXQncyB0eXBpY2FsbHkgYSBiaWcgY29tcGFueSB3 aXRoIGEgSHViIHNpdGUgdXNlZCB3aGVyZSBhZmZpbGlhdGVzIGhhdmUgZGVkaWNhdGVkIHJlc291 cmNlcyBpbiB0aGUgSHViIHNpdGUsIGFuZCBhZmZpbGlhdGVzIG11c3Qgbm90IHRhbGsgdG8gZWFj aCBvdGhlciBvciBldmVuIHNoYXJlIHJlc291cmNlcy4gTm90ZSB0aGF0IEkgcHV0dGVkICJwaHlz aWNhbCIgYmV0d2VlbiBxdW90ZXMgYmVjYXVzZSBpdCBjYW4gYmUgYSBuZXN0ZWQgbG9naWNhbCBh Y2Nlc3NlcyAuDQoNCiANCg0KIA0KDQpiKSAgICAgICJJTlRFUi1BUyBvcHRpb24gQSBsaWtlICIg Y2FzZSA6IHRoaXMgaXMgdGhlIGJhY2sgdG8gYmFjayBWUkYgY2FzZSwgYXMgcHJldmlvdXNseSBz aW5nbGUgInBoeXNpY2FsIiBhY2Nlc3MgYW5kIG11bHRpcGxlIGxvZ2ljYWwgYWNjZXNzZXMgb24g dG9wIGVhY2ggb25lIHBvaW50aW5nIHRvIGEgc2VwYXJhdGUgVlBOLiBJIHB1dHRlZCBpbnRlckFT LCBidXQgdGhpcyBjYW4gYmUgImludHJhLUFTIiB3aXRoIGlCR1AgYmFjayB0byBiYWNrIFZSRnMg YWxzbyAoaW50ZXJuYWwgREMgZm9yIGV4YW1wbGUpDQoNCiANCg0KYykgICAgICAgV2hhdCBhYm91 dCBvcHRpb24gQiA/IERvIHdlIGNvbnNpZGVyIG9wdGlvbiBCIGFzIGEgc2VydmljZSA/IEkgd291 bGQgbm90IGJlIGluIGZhdm9yIG9mIHRoYXQuIE9wdGlvbiBCIHNldHVwcyBhcmUgcmVhbGx5IHBh cnRpY3VsYXIgaW4gdGVybSBvZiBkZXNpZ24sIHNlY3VyaXR5IC4gIFNvIEkgd291bGQgbGlrZSB0 byBoYXZlIG9wdGlvbiBCIG91dCBvZiBzY29wZS4NCg0KIA0KDQogDQoNCkV2ZW4gaWYgYSkgYW5k IGIpIGFyZSBzZXBhcmF0ZWQgdXNlIGNhc2VzIGZyb20gYSBzZXJ2aWNlIHBvaW50IG9mIHZpZXcs IHRoZXNlIGFyZSBzaW1pbGFyIGluIHRlcm0gb2YgbW9kZWxpbmcuDQoNCiANCg0KVG9kYXkgd2Ug Y2FuIG1vZGVsIGl0IGhhcyBhIGNvbGxlY3Rpb24gb2Ygc2VwYXJhdGVkIHNpdGVzIHdpdGhvdXQg YW55IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGVhY2ggb3RoZXIuIFRoZSBvdGhlciBwb2ludCBpcyB0 aGF0IHdlIGNhbm5vdCBleHByZXNzIGFueSAgcHJvcGVydHkgb2YgdGhlICJwaHlzaWNhbCIgYXR0 YWNobWVudCBidXQgdGhlcmUgbWF5IGZldyAoZW5jcnlwdGlvbiA/KS4gV2UgY2FuIGtlZXAgdGhl IG1vZGVsIGFzIGl0IGlzIHdpdGggdGhpcyBsaW1pdGF0aW9uIG9yIHdlIGNhbiBjcmVhdGUgc2l0 ZSBhbmQgc3ViLXNpdGUgaGllcmFyY2h5IHdoaWNoIGFzIEkgYWxyZWFkeSBzYWlkIG1heSBjb21w bGV4aWZ5IHRoZSByZWFkaW5nIGFuZCB1c2FiaWxpdHkgKElNTykuDQoNCkl0IG1heSBsb29rIGxp a2UgdGhpcyA6DQoNCiANCg0KoaQgICAgICAgICBTaXRlcw0KDQpvICAgU2l0ZS1vbmx5LXBhcmFt ZXRlcnMgOg0KDQqh7CAgTG9jYXRpb24NCg0KoewgIERpdmVyc2l0eQ0KDQqh7CAgbWFuYWdlbWVu dA0KDQqh7CAgU2VjdXJpdHkNCg0KbyAgIFNwZWNpZmljLXBhcmFtZXRlcnMgOiA8LSB0byBiZSB1 c2VkIG9ubHkgaWYgdGhlcmUgaXMgbm8gc3Vic2l0ZS4NCg0KoewgIFZwbi1wb2xpY3kNCg0Koewg IFNlcnZpY2VzDQoNCqHsICBSb3V0aW5nLXByb3RvY29scw0KDQqh7CAgU2l0ZS1uZXR3b3JrLWFj Y2Vzc2VzDQoNCqGkICAgICAgICAgLi4NCg0KbyAgIFN1Yi1zaXRlcyA6IDwtIHRvIGJlIHVzZWQg aW4gY2FzZSBvZiBzdWIgc2l0ZXMgcHJlc2VudA0KDQqh7CAgU3BlY2lmaWMtcGFyYW1ldGVycyA6 DQoNCqGkICAgICAgICAgVnBuLXBvbGljeQ0KDQqhpCAgICAgICAgIFNlcnZpY2VzDQoNCqGkICAg ICAgICAgUm91dGluZy1wcm90b2NvbHMNCg0KoaQgICAgICAgICBTaXRlLW5ldHdvcmstYWNjZXNz ZXMNCg0KbyAgIC4NCg0KIA0KDQpJJ20gYWxzbyB3b25kZXJpbmcgaWYgYmVhcmVyIHBhcmFtZXRl cnMgbXVzdCBhbHNvIGJlIHRha2VuIG91dCBpbiB0aGlzIGNhc2UgYW5kIHB1dHRlZCBpbiB0aGUg c2l0ZS1vbmx5LXBhcmFtZXRlcnMuIA0KDQpUaGUgaGllcmFyY2h5IGJlY29tZXMgcmVhbGx5IGNv bXBsZXggaGVyZSBhbmQgSSB3b3VsZCBsaWtlIHRvIGtlZXAgaXQgYXMgc2ltcGxlIGFzIHBvc3Np YmxlLg0KDQogDQoNCiANCg0KV291bGQgYmUgZ29vZCB0byBoYXZlIG11bHRpcGxlIGZlZWRiYWNr cyBmcm9tIHRoZSBXRyB0byBzZWUgd2hlcmUgdGhlIGNvbnNlbnN1cyBpcy4NCg0KIA0KDQogDQoN Ck9yYW5nZSBsb2dvIDxodHRwOi8vd3d3Lm9yYW5nZS5jb20vPiANCg0KIA0KDQpTdGVwaGFuZSBM aXRrb3dza2kNCk5ldHdvcmsgQXJjaGl0ZWN0DQpPcmFuZ2UvU0NFL0VRVUFOVC9PSU5JUy9ORVQN Cg0KT3JhbmdlIEV4cGVydCBGdXR1cmUgTmV0d29ya3MNCg0KcGhvbmU6ICszMyAyIDIzIDI4IDQ5 IDgzIDxodHRwczovL21vbnNpLnNzby5mcmFuY2V0ZWxlY29tLmZyL2luZGV4LmFzcD90YXJnZXQ9 aHR0cCUzQSUyRiUyRmNsaWN2b2ljZS5zc28uZnJhbmNldGVsZWNvbS5mciUyRkNsaWN2b2ljZVYy JTJGVG9vbEJhci5kbyUzRmFjdGlvbiUzRGRlZmF1bHQlMjZyb290c2VydmljZSUzRFNJR05BVFVS RSUyNnRvJTNEKzMzJTIwMiUyMDIzJTIwMjglMjA0OSUyMDgzJTIwPg0KbW9iaWxlOiArMzMgNiAz NyA4NiA5NyA1MiA8aHR0cHM6Ly9tb25zaS5zc28uZnJhbmNldGVsZWNvbS5mci9pbmRleC5hc3A/ dGFyZ2V0PWh0dHAlM0ElMkYlMkZjbGljdm9pY2Uuc3NvLmZyYW5jZXRlbGVjb20uZnIlMkZDbGlj dm9pY2VWMiUyRlRvb2xCYXIuZG8lM0ZhY3Rpb24lM0RkZWZhdWx0JTI2cm9vdHNlcnZpY2UlM0RT SUdOQVRVUkUlMjZ0byUzRCszMyUyMDYlMjAzNyUyMDg2JTIwOTclMjA1MiUyMD4NCnN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tIDxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5j b20+ICANCg0KIA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoN ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpMM3NtIG1haWxpbmcgbGlzdA0KTDNzbUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMM3NtIG1haWxpbmcgbGlzdA0KTDNzbUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMM3NtIG1haWxpbmcg bGlzdA0KTDNzbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9sM3NtDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K TDNzbSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbDNzbQ0KDQo= From nobody Thu Feb 25 01:07:40 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26A31A8784 for ; Thu, 25 Feb 2016 01:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 D1EMOvd1_tXt for ; Thu, 25 Feb 2016 01:07:35 -0800 (PST) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id B30581A8785 for ; Thu, 25 Feb 2016 01:07:26 -0800 (PST) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id 3519FE00AE; Thu, 25 Feb 2016 18:07:26 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Thu, 25 Feb 2016 18:07:26 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 061684C005A; Thu, 25 Feb 2016 18:07:26 +0900 (JST) Received: from LTMC2153.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id EED8D4C0058; Thu, 25 Feb 2016 18:07:25 +0900 (JST) Received: from LTMC2153.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2153.kddi.com with ESMTP id u1P97P8p022783; Thu, 25 Feb 2016 18:07:25 +0900 Received: from LTMC2153.kddi.com.mid_60068846 (localhost.localdomain [127.0.0.1]) by LTMC2153.kddi.com with ESMTP id u1P8vNkJ009900; Thu, 25 Feb 2016 17:57:24 +0900 X-SA-MID: 60068846 Received: from KDDI1508PC0003 ([10.211.186.221] [10.211.186.221]) by post-smtp2.kddi.com with ESMTPA; Thu, 25 Feb 2016 17:57:23 +0900 From: "Ogaki, Kenichi" To: "'Qin Wu'" , , References: <11137_1452868271_569902AF_11137_18933_1_9E32478DFA9976438E7A22F69B08FF921683F2D0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <009a01d1518a$dccd16e0$966744a0$@kddi.com> <28946_1453107612_569CA99C_28946_1310_1_9E32478DFA9976438E7A22F69B08FF921683F60F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <000001d15266$38428380$a8c78a80$@kddi.com> <002c01d16d15$fb50c390$f1f24ab0$@kddi.com> <018d01d16f88$2776fd80$7664f880$@kddi.com> In-Reply-To: Date: Thu, 25 Feb 2016 17:57:24 +0900 Message-ID: <006901d16faa$8b37abe0$a1a703a0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5Bq8eqk2F/jjoJjePPJmqqbPofQJPFi+8Aw+DAN8BzQ7zqQKVjWu7AxyabOkBlpm9KgHO1o3cnmsr/yA= Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Modeling a site with multiple subsites X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 09:07:38 -0000 Hi Qin, See comments inline, please. Thanks, Kenichi -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: Thursday, February 25, 2016 5:48 PM To: Ogaki, Kenichi; stephane.litkowski@orange.com; l3sm@ietf.org Subject: RE: [L3sm] Modeling a site with multiple subsites If my understanding is correct, in the multi-homing case, we can use LAN = prefix in VPN-policy to bind each LAN to different VPNs, which allow us = connect one site to multiple VPNs, But I am not sure how to bind LAN = prefix through specific network access to one specific VPN, do we have = mechanism to support this? BGP? [KO] I proposed this as exercise as follows. But, I prefer the later = model proposal. https://mailarchive.ietf.org/arch/msg/l3sm/Mst8CP6lBfii_3pt_CKIoDsj6x8 By defining VPN policy under network access, it seems to mean one = network access should be associated with one or multiple LAN prefix, = when there is a route that need to be distributed to specific LAN, it = should be distributed to the specific LAN through specific network = access? Wrong? [KO] The current model can allow routing-protocols under = site-network-access.=20 -Qin -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C225=C8=D5 12:51 =CA=D5=BC=FE=C8=CB: Qin Wu; stephane.litkowski@orange.com; l3sm@ietf.org =D6=F7=CC=E2: RE: [L3sm] Modeling a site with multiple subsites Hi Qin, >Support subVPN case or multiple network accesses that is not for = multihoming? Not for multihoming from a site to a single VPN(or under a single = vpn-policy). The current model can only differentiate vpn-policy per sites. But, = there are many use cases to require vpn-policy per site-network-access. You can find the current limitation and use cases on the exchanges in = this thread. >I believe this issue is separated from what we discussed earlier about = extranet VPN policy. Yes, this is different issue. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu Sent: Thursday, February 25, 2016 12:57 PM To: Ogaki, Kenichi; stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Kenichi: Can you clarify a little bit the objective of the following proposal? Support subVPN case or multiple network accesses that is not for = multihoming? I believe this issue is separated from what we discussed earlier about = extranet VPN policy. -Qin -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: L3sm [mailto:l3sm-bounces@ietf.org] =B4=FA=B1=ED = Ogaki, Kenichi =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C222=C8=D5 10:09 =CA=D5=BC=FE=C8=CB: stephane.litkowski@orange.com; l3sm@ietf.org =D6=F7=CC=E2: Re: [L3sm] Modeling a site with multiple subsites Hi Stephane and All, >>How to you differentiate multihoming from your subVPN case? they are=20 >>two different >things. >As I wrote, we just have to *duplicate* vpn-policy under=20 >site-network-access. When an operator's use case requires multiVPN,=20 >then vpn-policy should be under sites as the current model does. >When the other operator requires subVPN, vpn-policy should just be=20 >under site- network-access. It's sufficient to use these two cases = exclusively. Here is a minimum modification proposal to the current model in order to = use these two cases exclusively. Only if a vpn-policy is not defined directly under sites, we can define = it under site-network-access. If something is grammatically wrong in terms of YANG and XPATH = expression, could anyone correct me? ... container site-network-accesses { list site-network-access { uses site-vpn-policy { refine vpn-policy { when "not(../../../vpn-policy)"; } } ... } ... } ... Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Tuesday, January 19, 2016 12:05 PM To: stephane.litkowski@orange.com; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi Stephane, >We cannot use site-network-access which is used for multihoming only. Why do we have to use site-network-access only for multihoming? This is = intuitively mapped to a logical access as you wrote. >How to you differentiate multihoming from your subVPN case? they are = two different things. As I wrote, we just have to *duplicate* vpn-policy under = site-network-access. When an operator's use case requires multiVPN, then = vpn-policy should be under sites as the current model does. When the other operator requires subVPN, vpn-policy should just be under = site-network-access. It's sufficient to use these two cases exclusively. >Could you provide more technical detail so I will be able to understand = what exactly you are trying to achieve ? Our existing commercial service allows the *logically* following = diagram. PE1, PE2 and PE3 can be VRFs inside a single physical PE, or may be = physically separate PEs. Same as CEs. L2SW can be QinQ sub-interfaces on = a single physical PE depending on the above case. Then, we may map each element like this. sites: A customer premises connected via QinQ (stag 100) sub-sites: A customer premises' layer 2 segment separated by .1Q (ctag = 10 or 20), a ctag segment can include multiple logical accesses with bgp = peer per logical access. For example, PE1 has a bgp peer with CE1, and = PE2 has a different bgp peer with CE2. In this case, when VPN X only talks to LAN X, we need subVPN inside = sub-sites. But, we can deal with a sub-sites as a sites for the = simplicity to minimally extend the current model. Even so, we still need = vpn-policy per site-network-access. +-----------------------------+ +------------------------------+ | | | | | /---\ ctag 10 | | ctag 10 /---\ | | VPN A-+ PE1 +--------+ | | +--------+ CE1 +-LAN A | | \---/ | | | | \---/ | | | | | | | | /---\ctag 10+-+----+ |stag 100| +----+-+ctag 10/---\ | | VPN B-+ PE2 +------+ L2SW +-+--------+-+ L2SW +------+ CE2 +-LAN B | | \---/ +-+----+ | | +----+-+ \---/ | | | | | | | | /---\ctag 20 | | | | ctag 20 /---\ | | VPN C-+ PE3 +--------+ | | +--------+ CE3 +-LAN C | | \---/ | | \---/ | | | | | +-----------------------------+ +------------------------------+ Central Office Customer Premises All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Monday, January 18, 2016 6:00 PM To: Ogaki, Kenichi; l3sm@ietf.org Subject: Re: [L3sm] Modeling a site with multiple subsites Hi, We cannot use site-network-access which is used for multihoming only. How to you differentiate multihoming from your subVPN case ? they are = two different things. So I'm completely against using site-network-accesses as a subVPN can be = also multihomed ... > FYI, our commercial service honestly has a similar element as = sub-sites, corresponding to vlan, but we still allows multiple vpns and = bgp peers, each different vpn access per peer, within a single vlan. Could you provide more technical detail so I will be able to understand = what exactly you are trying to achieve ? Best Regards, Stephane -----Original Message----- From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] Sent: Monday, January 18, 2016 01:55 To: LITKOWSKI Stephane SCE/OINIS; l3sm@ietf.org Subject: RE: [L3sm] Modeling a site with multiple subsites Hi Stephane, >Single "physical" access between SP and customer, but multiple = sub-accesses on top (VLAN, PPP sessions, or whatever ...), each one = pointing to a specific VPN. As you wrote above in the scenario a) and b), vpn-policy only have to be = controlled per logical access, equivalent to the site-network-access in = the current model. To solve the issue as simple as possible, it's = sufficient to duplicate vpn-policy under site-network-access. In these cases, a completely different conceptual element, sub-sites, is = not required. This must bring a complexity, and sometimes hard to be = understood, depending on operator's usecase.=20 Although we shouldn't discuss the device modelling, the granularity of = sub-sites corresponds to a VRF's one from the viewpoint of vpn-policy. = In this case, nobody intuitively imagines (sub-)sites from VRF, because = it's commonly in a single physical box. FYI, our commercial service honestly has a similar element as sub-sites, = corresponding to vlan, but we still allows multiple vpns and bgp peers, = each different vpn access per peer, within a single vlan. All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Friday, January 15, 2016 11:31 PM To: l3sm@ietf.org Subject: [L3sm] Modeling a site with multiple subsites [Creating another topic for better followup] =20 Today the model has the ability to create sites, a site can be = multihomed to the network thanks to the site-network-access sub-tree. =20 Now the question is how to we model such scenarios : =20 a) "SUBVPN case" : Single "physical" access between SP and = customer, but multiple sub-accesses on top (VLAN, PPP sessions, or = whatever .), each one pointing to a specific VPN. It is expected for the = customer to ensure flow separation (VRF lite, VLANs .). It's typically a = big company with a Hub site used where affiliates have dedicated = resources in the Hub site, and affiliates must not talk to each other or = even share resources. Note that I putted "physical" between quotes = because it can be a nested logical accesses . =20 =20 b) "INTER-AS option A like " case : this is the back to back VRF = case, as previously single "physical" access and multiple logical = accesses on top each one pointing to a separate VPN. I putted interAS, = but this can be "intra-AS" with iBGP back to back VRFs also (internal DC = for example) =20 c) What about option B ? Do we consider option B as a service ? I = would not be in favor of that. Option B setups are really particular in = term of design, security . So I would like to have option B out of = scope. =20 =20 Even if a) and b) are separated use cases from a service point of view, = these are similar in term of modeling. =20 Today we can model it has a collection of separated sites without any = relationship between each other. The other point is that we cannot = express any property of the "physical" attachment but there may few = (encryption ?). We can keep the model as it is with this limitation or = we can create site and sub-site hierarchy which as I already said may = complexify the reading and usability (IMO). It may look like this : =20 =A1=A4 Sites o Site-only-parameters : =A1=EC Location =A1=EC Diversity =A1=EC management =A1=EC Security o Specific-parameters : <- to be used only if there is no subsite. =A1=EC Vpn-policy =A1=EC Services =A1=EC Routing-protocols =A1=EC Site-network-accesses =A1=A4 .. o Sub-sites : <- to be used in case of sub sites present =A1=EC Specific-parameters : =A1=A4 Vpn-policy =A1=A4 Services =A1=A4 Routing-protocols =A1=A4 Site-network-accesses o . =20 I'm also wondering if bearer parameters must also be taken out in this = case and putted in the site-only-parameters.=20 The hierarchy becomes really complex here and I would like to keep it as = simple as possible. =20 =20 Would be good to have multiple feedbacks from the WG to see where the = consensus is. =20 =20 Orange logo =20 =20 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 =20 =20 =20 _________________________________________________________________________= ________________________________________________ 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 _______________________________________________ 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 _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Thu Feb 25 01:39:48 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7561A88FA for ; Thu, 25 Feb 2016 01:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 ohO_Xh6dv4YL for ; Thu, 25 Feb 2016 01:39:42 -0800 (PST) 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 C9D231A88F9 for ; Thu, 25 Feb 2016 01:39:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEZ23944; Thu, 25 Feb 2016 09:39:39 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 09:39:37 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 17:39:34 +0800 From: Qin Wu To: "Ogaki, Kenichi" , "stephane.litkowski@orange.com" , "l3sm@ietf.org" Thread-Topic: [L3sm] Modeling a site with multiple subsites Thread-Index: AdFPnqCmtWfFPEtQT6m/5Yx5kcaoDABqSt8AABDyLYAAJeSogAar8U0AAKsvQfD//4regP//O49AgAEJOQD//3CkcA== Date: Thu, 25 Feb 2016 09:39:34 +0000 Message-ID: References: <11137_1452868271_569902AF_11137_18933_1_9E32478DFA9976438E7A22F69B08FF921683F2D0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <009a01d1518a$dccd16e0$966744a0$@kddi.com> <28946_1453107612_569CA99C_28946_1310_1_9E32478DFA9976438E7A22F69B08FF921683F60F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <000001d15266$38428380$a8c78a80$@kddi.com> <002c01d16d15$fb50c390$f1f24ab0$@kddi.com> <018d01d16f88$2776fd80$7664f880$@kddi.com> <006901d16faa$8b37abe0$a1a703a0$@kddi.com> In-Reply-To: <006901d16faa$8b37abe0$a1a703a0$@kddi.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.208] 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.0A090204.56CECBDB.008F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0fc334dc862f576fa83551b6ce03c7ca Archived-At: Subject: Re: [L3sm] Modeling a site with multiple subsites X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 09:39:47 -0000 VGhhbmsgZm9yIGNsYXJpZmljYXRpb24gYW5kIGJyaW5naW5nIHVwIHlvdXIgZWFybGllciBwcm9w b3NhbC4NCk15IGNvbmNlcm4gaXMgZG8gd2UgaGF2ZSBleGlzdGluZyBtZWNoYW5pc20gdG8gc3Vw cG9ydCBkaXN0cmlidXRlIHJvdXRlIHRvIHNwZWNpZmljIExBTiB0aHJvdWdoIHNwZWNpZmljIG5l dHdvcmsgYWNjZXNzPw0KSSB0aGluayB3ZSBzaG91bGQgcmV2aWV3IHlvdXIgdHdvIHByb3Bvc2Fs czoNCk9uZSBpcyB0byBwdXQgVlBOIHBvbGljeSB1bmRlciBzaXRlLW5ldHdvcmstYWNjZXNzLA0K VGhlIG90aGVyIGlzIHRvIHB1dCByb3V0aW5nIHByb3RvY29sIHVuZGVyIHNpdGUtbmV0d29yay1h Y2Nlc3MsDQpJbiBib3RoIHByb3Bvc2FscywgeW91IGhhdmUgTEFOIHByZWZpeCBhc3NvY2lhdGVk IHdpdGggc3BlY2lmaWMgbmV0d29yayBhY2Nlc3MuDQoNCi1RaW4NCi0tLS0t08q8/tStvP4tLS0t LQ0Kt6K8/sjLOiBPZ2FraSwgS2VuaWNoaSBbbWFpbHRvOmtlLW9vZ2FraUBrZGRpLmNvbV0gDQq3 osvNyrG85DogMjAxNsTqMtTCMjXI1SAxNjo1Nw0KytW8/sjLOiBRaW4gV3U7IHN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tOyBsM3NtQGlldGYub3JnDQrW98ziOiBSRTogW0wzc21dIE1vZGVs aW5nIGEgc2l0ZSB3aXRoIG11bHRpcGxlIHN1YnNpdGVzDQoNCkhpIFFpbiwNCg0KU2VlIGNvbW1l bnRzIGlubGluZSwgcGxlYXNlLg0KDQpUaGFua3MsDQpLZW5pY2hpDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBRaW4gV3UgW21haWx0bzpiaWxsLnd1QGh1YXdlaS5jb21dDQpT ZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjUsIDIwMTYgNTo0OCBQTQ0KVG86IE9nYWtpLCBLZW5p Y2hpOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBpZXRmLm9yZw0KU3ViamVj dDogUkU6IFtMM3NtXSBNb2RlbGluZyBhIHNpdGUgd2l0aCBtdWx0aXBsZSBzdWJzaXRlcw0KDQpJ ZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIGluIHRoZSBtdWx0aS1ob21pbmcgY2FzZSwg d2UgY2FuIHVzZSBMQU4gcHJlZml4IGluIFZQTi1wb2xpY3kgdG8gYmluZCBlYWNoIExBTiB0byBk aWZmZXJlbnQgVlBOcywgd2hpY2ggYWxsb3cgdXMgY29ubmVjdCBvbmUgc2l0ZSB0byBtdWx0aXBs ZSBWUE5zLCBCdXQgSSBhbSBub3Qgc3VyZSBob3cgdG8gYmluZCBMQU4gcHJlZml4IHRocm91Z2gg c3BlY2lmaWMgbmV0d29yayBhY2Nlc3MgdG8gb25lIHNwZWNpZmljIFZQTiwgZG8gd2UgaGF2ZSBt ZWNoYW5pc20gdG8gc3VwcG9ydCB0aGlzPyBCR1A/DQoNCltLT10gSSBwcm9wb3NlZCB0aGlzIGFz IGV4ZXJjaXNlIGFzIGZvbGxvd3MuIEJ1dCwgSSBwcmVmZXIgdGhlIGxhdGVyIG1vZGVsIHByb3Bv c2FsLg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9sM3NtL01zdDhDUDZs QmZpaV8zcHRfQ0tJb0RzajZ4OA0KDQoNCkJ5IGRlZmluaW5nIFZQTiBwb2xpY3kgdW5kZXIgbmV0 d29yayBhY2Nlc3MsIGl0IHNlZW1zIHRvIG1lYW4gb25lIG5ldHdvcmsgYWNjZXNzIHNob3VsZCBi ZSBhc3NvY2lhdGVkIHdpdGggb25lIG9yIG11bHRpcGxlIExBTiBwcmVmaXgsIHdoZW4gdGhlcmUg aXMgYSByb3V0ZSB0aGF0IG5lZWQgdG8gYmUgZGlzdHJpYnV0ZWQgdG8gc3BlY2lmaWMgTEFOLCBp dCBzaG91bGQgYmUgZGlzdHJpYnV0ZWQgdG8gdGhlIHNwZWNpZmljIExBTiB0aHJvdWdoIHNwZWNp ZmljIG5ldHdvcmsgYWNjZXNzPyBXcm9uZz8NCg0KW0tPXSBUaGUgY3VycmVudCBtb2RlbCBjYW4g YWxsb3cgcm91dGluZy1wcm90b2NvbHMgdW5kZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzcy4gDQoNCg0K LVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IE9nYWtpLCBLZW5pY2hpIFttYWlsdG86 a2Utb29nYWtpQGtkZGkuY29tXQ0Kt6LLzcqxvOQ6IDIwMTbE6jLUwjI1yNUgMTI6NTENCsrVvP7I yzogUWluIFd1OyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBpZXRmLm9yZw0K 1vfM4jogUkU6IFtMM3NtXSBNb2RlbGluZyBhIHNpdGUgd2l0aCBtdWx0aXBsZSBzdWJzaXRlcw0K DQpIaSBRaW4sDQoNCj5TdXBwb3J0IHN1YlZQTiBjYXNlIG9yIG11bHRpcGxlIG5ldHdvcmsgYWNj ZXNzZXMgdGhhdCBpcyBub3QgZm9yIG11bHRpaG9taW5nPw0KDQpOb3QgZm9yIG11bHRpaG9taW5n IGZyb20gYSBzaXRlIHRvIGEgc2luZ2xlIFZQTihvciB1bmRlciBhIHNpbmdsZSB2cG4tcG9saWN5 KS4NClRoZSBjdXJyZW50IG1vZGVsIGNhbiBvbmx5IGRpZmZlcmVudGlhdGUgdnBuLXBvbGljeSBw ZXIgc2l0ZXMuIEJ1dCwgdGhlcmUgYXJlIG1hbnkgdXNlIGNhc2VzIHRvIHJlcXVpcmUgdnBuLXBv bGljeSBwZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzcy4NCllvdSBjYW4gZmluZCB0aGUgY3VycmVudCBs aW1pdGF0aW9uIGFuZCB1c2UgY2FzZXMgb24gdGhlIGV4Y2hhbmdlcyBpbiB0aGlzIHRocmVhZC4N Cg0KPkkgYmVsaWV2ZSB0aGlzIGlzc3VlIGlzIHNlcGFyYXRlZCBmcm9tIHdoYXQgd2UgZGlzY3Vz c2VkIGVhcmxpZXIgYWJvdXQgZXh0cmFuZXQgVlBOIHBvbGljeS4NClllcywgdGhpcyBpcyBkaWZm ZXJlbnQgaXNzdWUuDQoNClRoYW5rcywNCktlbmljaGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBRaW4gV3UNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNSwgMjAxNiAxMjo1NyBQTQ0K VG86IE9nYWtpLCBLZW5pY2hpOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgbDNzbUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtMM3NtXSBNb2RlbGluZyBhIHNpdGUgd2l0aCBtdWx0aXBs ZSBzdWJzaXRlcw0KDQpLZW5pY2hpOg0KQ2FuIHlvdSBjbGFyaWZ5IGEgbGl0dGxlIGJpdCB0aGUg b2JqZWN0aXZlIG9mIHRoZSBmb2xsb3dpbmcgcHJvcG9zYWw/DQpTdXBwb3J0IHN1YlZQTiBjYXNl IG9yIG11bHRpcGxlIG5ldHdvcmsgYWNjZXNzZXMgdGhhdCBpcyBub3QgZm9yIG11bHRpaG9taW5n Pw0KSSBiZWxpZXZlIHRoaXMgaXNzdWUgaXMgc2VwYXJhdGVkIGZyb20gd2hhdCB3ZSBkaXNjdXNz ZWQgZWFybGllciBhYm91dCBleHRyYW5ldCBWUE4gcG9saWN5Lg0KDQotUWluDQotLS0tLdPKvP7U rbz+LS0tLS0NCreivP7IyzogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SBPZ2FraSwgS2VuaWNoaQ0Kt6LLzcqxvOQ6IDIwMTbE6jLUwjIyyNUgMTA6MDkNCsrVvP7Iyzog c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5vcmcNCtb3zOI6IFJlOiBb TDNzbV0gTW9kZWxpbmcgYSBzaXRlIHdpdGggbXVsdGlwbGUgc3Vic2l0ZXMNCg0KSGkgU3RlcGhh bmUgYW5kIEFsbCwNCg0KPj5Ib3cgdG8geW91IGRpZmZlcmVudGlhdGUgbXVsdGlob21pbmcgZnJv bSB5b3VyIHN1YlZQTiBjYXNlPyB0aGV5IGFyZSANCj4+dHdvIGRpZmZlcmVudA0KPnRoaW5ncy4N Cg0KPkFzIEkgd3JvdGUsIHdlIGp1c3QgaGF2ZSB0byAqZHVwbGljYXRlKiB2cG4tcG9saWN5IHVu ZGVyIA0KPnNpdGUtbmV0d29yay1hY2Nlc3MuIFdoZW4gYW4gb3BlcmF0b3IncyB1c2UgY2FzZSBy ZXF1aXJlcyBtdWx0aVZQTiwgDQo+dGhlbiB2cG4tcG9saWN5IHNob3VsZCBiZSB1bmRlciBzaXRl cyBhcyB0aGUgY3VycmVudCBtb2RlbCBkb2VzLg0KPldoZW4gdGhlIG90aGVyIG9wZXJhdG9yIHJl cXVpcmVzIHN1YlZQTiwgdnBuLXBvbGljeSBzaG91bGQganVzdCBiZSANCj51bmRlciBzaXRlLSBu ZXR3b3JrLWFjY2Vzcy4gSXQncyBzdWZmaWNpZW50IHRvIHVzZSB0aGVzZSB0d28gY2FzZXMgZXhj bHVzaXZlbHkuDQoNCkhlcmUgaXMgYSBtaW5pbXVtIG1vZGlmaWNhdGlvbiBwcm9wb3NhbCB0byB0 aGUgY3VycmVudCBtb2RlbCBpbiBvcmRlciB0byB1c2UgdGhlc2UgdHdvIGNhc2VzIGV4Y2x1c2l2 ZWx5Lg0KT25seSBpZiBhIHZwbi1wb2xpY3kgaXMgbm90IGRlZmluZWQgZGlyZWN0bHkgdW5kZXIg c2l0ZXMsIHdlIGNhbiBkZWZpbmUgaXQgdW5kZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzcy4NCklmIHNv bWV0aGluZyBpcyBncmFtbWF0aWNhbGx5IHdyb25nIGluIHRlcm1zIG9mIFlBTkcgYW5kIFhQQVRI IGV4cHJlc3Npb24sIGNvdWxkIGFueW9uZSBjb3JyZWN0IG1lPw0KDQouLi4NCmNvbnRhaW5lciBz aXRlLW5ldHdvcmstYWNjZXNzZXMgew0KICAgIGxpc3Qgc2l0ZS1uZXR3b3JrLWFjY2VzcyB7DQog ICAgICAgIHVzZXMgc2l0ZS12cG4tcG9saWN5IHsNCiAgICAgICAgICAgIHJlZmluZSB2cG4tcG9s aWN5IHsNCiAgICAgICAgICAgICAgICB3aGVuICJub3QoLi4vLi4vLi4vdnBuLXBvbGljeSkiOw0K ICAgICAgICAgICAgfQ0KICAgICAgICB9DQogICAgLi4uDQogICAgfQ0KLi4uDQp9DQouLi4NCg0K VGhhbmtzLA0KS2VuaWNoaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTDNz bSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE9nYWtpLCBLZW5p Y2hpDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDE5LCAyMDE2IDEyOjA1IFBNDQpUbzogc3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb207IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTDNz bV0gTW9kZWxpbmcgYSBzaXRlIHdpdGggbXVsdGlwbGUgc3Vic2l0ZXMNCg0KSGkgU3RlcGhhbmUs DQoNCj5XZSBjYW5ub3QgdXNlIHNpdGUtbmV0d29yay1hY2Nlc3Mgd2hpY2ggaXMgdXNlZCBmb3Ig bXVsdGlob21pbmcgb25seS4NCg0KV2h5IGRvIHdlIGhhdmUgdG8gdXNlIHNpdGUtbmV0d29yay1h Y2Nlc3Mgb25seSBmb3IgbXVsdGlob21pbmc/IFRoaXMgaXMgaW50dWl0aXZlbHkgbWFwcGVkIHRv IGEgbG9naWNhbCBhY2Nlc3MgYXMgeW91IHdyb3RlLg0KDQoNCj5Ib3cgdG8geW91IGRpZmZlcmVu dGlhdGUgbXVsdGlob21pbmcgZnJvbSB5b3VyIHN1YlZQTiBjYXNlPyB0aGV5IGFyZSB0d28gZGlm ZmVyZW50IHRoaW5ncy4NCg0KQXMgSSB3cm90ZSwgd2UganVzdCBoYXZlIHRvICpkdXBsaWNhdGUq IHZwbi1wb2xpY3kgdW5kZXIgc2l0ZS1uZXR3b3JrLWFjY2Vzcy4gV2hlbiBhbiBvcGVyYXRvcidz IHVzZSBjYXNlIHJlcXVpcmVzIG11bHRpVlBOLCB0aGVuIHZwbi1wb2xpY3kgc2hvdWxkIGJlIHVu ZGVyIHNpdGVzIGFzIHRoZSBjdXJyZW50IG1vZGVsIGRvZXMuDQpXaGVuIHRoZSBvdGhlciBvcGVy YXRvciByZXF1aXJlcyBzdWJWUE4sIHZwbi1wb2xpY3kgc2hvdWxkIGp1c3QgYmUgdW5kZXIgc2l0 ZS1uZXR3b3JrLWFjY2Vzcy4gSXQncyBzdWZmaWNpZW50IHRvIHVzZSB0aGVzZSB0d28gY2FzZXMg ZXhjbHVzaXZlbHkuDQoNCg0KPkNvdWxkIHlvdSBwcm92aWRlIG1vcmUgdGVjaG5pY2FsIGRldGFp bCBzbyBJIHdpbGwgYmUgYWJsZSB0byB1bmRlcnN0YW5kIHdoYXQgZXhhY3RseSB5b3UgYXJlIHRy eWluZyB0byBhY2hpZXZlID8NCg0KT3VyIGV4aXN0aW5nIGNvbW1lcmNpYWwgc2VydmljZSBhbGxv d3MgdGhlICpsb2dpY2FsbHkqIGZvbGxvd2luZyBkaWFncmFtLg0KUEUxLCBQRTIgYW5kIFBFMyBj YW4gYmUgVlJGcyBpbnNpZGUgYSBzaW5nbGUgcGh5c2ljYWwgUEUsIG9yIG1heSBiZSBwaHlzaWNh bGx5IHNlcGFyYXRlIFBFcy4gU2FtZSBhcyBDRXMuIEwyU1cgY2FuIGJlIFFpblEgc3ViLWludGVy ZmFjZXMgb24gYSBzaW5nbGUgcGh5c2ljYWwgUEUgZGVwZW5kaW5nIG9uIHRoZSBhYm92ZSBjYXNl Lg0KDQpUaGVuLCB3ZSBtYXkgbWFwIGVhY2ggZWxlbWVudCBsaWtlIHRoaXMuDQoNCnNpdGVzOiBB IGN1c3RvbWVyIHByZW1pc2VzIGNvbm5lY3RlZCB2aWEgUWluUSAoc3RhZyAxMDApDQpzdWItc2l0 ZXM6IEEgY3VzdG9tZXIgcHJlbWlzZXMnIGxheWVyIDIgc2VnbWVudCBzZXBhcmF0ZWQgYnkgLjFR IChjdGFnIDEwIG9yIDIwKSwgYSBjdGFnIHNlZ21lbnQgY2FuIGluY2x1ZGUgbXVsdGlwbGUgbG9n aWNhbCBhY2Nlc3NlcyB3aXRoIGJncCBwZWVyIHBlciBsb2dpY2FsIGFjY2Vzcy4gRm9yIGV4YW1w bGUsIFBFMSBoYXMgYSBiZ3AgcGVlciB3aXRoIENFMSwgYW5kIFBFMiBoYXMgYSBkaWZmZXJlbnQg YmdwIHBlZXIgd2l0aCBDRTIuDQoNCkluIHRoaXMgY2FzZSwgd2hlbiBWUE4gWCBvbmx5IHRhbGtz IHRvIExBTiBYLCB3ZSBuZWVkIHN1YlZQTiBpbnNpZGUgc3ViLXNpdGVzLiBCdXQsIHdlIGNhbiBk ZWFsIHdpdGggYSBzdWItc2l0ZXMgYXMgYSBzaXRlcyBmb3IgdGhlIHNpbXBsaWNpdHkgdG8gbWlu aW1hbGx5IGV4dGVuZCB0aGUgY3VycmVudCBtb2RlbC4gRXZlbiBzbywgd2Ugc3RpbGwgbmVlZCB2 cG4tcG9saWN5IHBlciBzaXRlLW5ldHdvcmstYWNjZXNzLg0KDQorLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCnwgICAgICAgIC8tLS1cIGN0YWcgMTAgICAgICAgIHwgICAgICAgIHwgICAg ICAgIGN0YWcgMTAgLy0tLVwgICAgICAgICB8DQp8IFZQTiBBLSsgUEUxICstLS0tLS0tLSsgICAg ICB8ICAgICAgICB8ICAgICAgKy0tLS0tLS0tKyBDRTEgKy1MQU4gQSAgfA0KfCAgICAgICAgXC0t LS8gICAgICAgICB8ICAgICAgfCAgICAgICAgfCAgICAgIHwgICAgICAgICBcLS0tLyAgICAgICAg IHwNCnwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwgICAgICAgIHwgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICB8DQp8ICAgICAgICAvLS0tXGN0YWcgMTArLSstLS0tKyB8c3RhZyAx MDB8ICstLS0tKy0rY3RhZyAxMC8tLS1cICAgICAgICAgfA0KfCBWUE4gQi0rIFBFMiArLS0tLS0t KyBMMlNXICstKy0tLS0tLS0tKy0rIEwyU1cgKy0tLS0tLSsgQ0UyICstTEFOIEIgIHwNCnwgICAg ICAgIFwtLS0vICAgICAgICstKy0tLS0rIHwgICAgICAgIHwgKy0tLS0rLSsgICAgICAgXC0tLS8g ICAgICAgICB8DQp8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgICB8ICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgfA0KfCAgICAgICAgLy0tLVxjdGFnIDIwICB8ICAgICAg fCAgICAgICAgfCAgICAgIHwgY3RhZyAyMCAvLS0tXCAgICAgICAgIHwNCnwgVlBOIEMtKyBQRTMg Ky0tLS0tLS0tKyAgICAgIHwgICAgICAgIHwgICAgICArLS0tLS0tLS0rIENFMyArLUxBTiBDICB8 DQp8ICAgICAgICBcLS0tLyAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAg IFwtLS0vICAgICAgICAgfA0KfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCistLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAg ICBDZW50cmFsIE9mZmljZSAgICAgICAgICAgICAgICAgICAgICAgIEN1c3RvbWVyIFByZW1pc2Vz DQoNCkFsbCB0aGUgYmVzdCwNCktlbmljaGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBz dGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDE4LCAy MDE2IDY6MDAgUE0NClRvOiBPZ2FraSwgS2VuaWNoaTsgbDNzbUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtMM3NtXSBNb2RlbGluZyBhIHNpdGUgd2l0aCBtdWx0aXBsZSBzdWJzaXRlcw0KDQpIaSwN Cg0KV2UgY2Fubm90IHVzZSBzaXRlLW5ldHdvcmstYWNjZXNzIHdoaWNoIGlzIHVzZWQgZm9yIG11 bHRpaG9taW5nIG9ubHkuDQpIb3cgdG8geW91IGRpZmZlcmVudGlhdGUgbXVsdGlob21pbmcgZnJv bSB5b3VyIHN1YlZQTiBjYXNlID8gdGhleSBhcmUgdHdvIGRpZmZlcmVudCB0aGluZ3MuDQpTbyBJ J20gY29tcGxldGVseSBhZ2FpbnN0IHVzaW5nIHNpdGUtbmV0d29yay1hY2Nlc3NlcyBhcyBhIHN1 YlZQTiBjYW4gYmUgYWxzbyBtdWx0aWhvbWVkIC4uLg0KDQo+IEZZSSwgb3VyIGNvbW1lcmNpYWwg c2VydmljZSBob25lc3RseSBoYXMgYSBzaW1pbGFyIGVsZW1lbnQgYXMgc3ViLXNpdGVzLCBjb3Jy ZXNwb25kaW5nIHRvIHZsYW4sIGJ1dCB3ZSBzdGlsbCBhbGxvd3MgbXVsdGlwbGUgdnBucyBhbmQg YmdwIHBlZXJzLCBlYWNoIGRpZmZlcmVudCB2cG4gYWNjZXNzIHBlciBwZWVyLCB3aXRoaW4gYSBz aW5nbGUgdmxhbi4NCkNvdWxkIHlvdSBwcm92aWRlIG1vcmUgdGVjaG5pY2FsIGRldGFpbCBzbyBJ IHdpbGwgYmUgYWJsZSB0byB1bmRlcnN0YW5kIHdoYXQgZXhhY3RseSB5b3UgYXJlIHRyeWluZyB0 byBhY2hpZXZlID8NCg0KQmVzdCBSZWdhcmRzLA0KDQpTdGVwaGFuZQ0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPZ2FraSwgS2VuaWNoaSBbbWFpbHRvOmtlLW9vZ2FraUBr ZGRpLmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxOCwgMjAxNiAwMTo1NQ0KVG86IExJVEtP V1NLSSBTdGVwaGFuZSBTQ0UvT0lOSVM7IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbTDNz bV0gTW9kZWxpbmcgYSBzaXRlIHdpdGggbXVsdGlwbGUgc3Vic2l0ZXMNCg0KSGkgU3RlcGhhbmUs DQoNCj5TaW5nbGUgInBoeXNpY2FsIiBhY2Nlc3MgYmV0d2VlbiBTUCBhbmQgY3VzdG9tZXIsIGJ1 dCBtdWx0aXBsZSBzdWItYWNjZXNzZXMgb24gdG9wIChWTEFOLCBQUFAgc2Vzc2lvbnMsIG9yIHdo YXRldmVyIC4uLiksIGVhY2ggb25lIHBvaW50aW5nIHRvIGEgc3BlY2lmaWMgVlBOLg0KDQpBcyB5 b3Ugd3JvdGUgYWJvdmUgaW4gdGhlIHNjZW5hcmlvIGEpIGFuZCBiKSwgdnBuLXBvbGljeSBvbmx5 IGhhdmUgdG8gYmUgY29udHJvbGxlZCBwZXIgbG9naWNhbCBhY2Nlc3MsIGVxdWl2YWxlbnQgdG8g dGhlIHNpdGUtbmV0d29yay1hY2Nlc3MgaW4gdGhlIGN1cnJlbnQgbW9kZWwuIFRvIHNvbHZlIHRo ZSBpc3N1ZSBhcyBzaW1wbGUgYXMgcG9zc2libGUsIGl0J3Mgc3VmZmljaWVudCB0byBkdXBsaWNh dGUgdnBuLXBvbGljeSB1bmRlciBzaXRlLW5ldHdvcmstYWNjZXNzLg0KSW4gdGhlc2UgY2FzZXMs IGEgY29tcGxldGVseSBkaWZmZXJlbnQgY29uY2VwdHVhbCBlbGVtZW50LCBzdWItc2l0ZXMsIGlz IG5vdCByZXF1aXJlZC4gVGhpcyBtdXN0IGJyaW5nIGEgY29tcGxleGl0eSwgYW5kIHNvbWV0aW1l cyBoYXJkIHRvIGJlIHVuZGVyc3Rvb2QsIGRlcGVuZGluZyBvbiBvcGVyYXRvcidzIHVzZWNhc2Uu IA0KQWx0aG91Z2ggd2Ugc2hvdWxkbid0IGRpc2N1c3MgdGhlIGRldmljZSBtb2RlbGxpbmcsIHRo ZSBncmFudWxhcml0eSBvZiBzdWItc2l0ZXMgY29ycmVzcG9uZHMgdG8gYSBWUkYncyBvbmUgZnJv bSB0aGUgdmlld3BvaW50IG9mIHZwbi1wb2xpY3kuIEluIHRoaXMgY2FzZSwgbm9ib2R5IGludHVp dGl2ZWx5IGltYWdpbmVzIChzdWItKXNpdGVzIGZyb20gVlJGLCBiZWNhdXNlIGl0J3MgY29tbW9u bHkgaW4gYSBzaW5nbGUgcGh5c2ljYWwgYm94Lg0KDQpGWUksIG91ciBjb21tZXJjaWFsIHNlcnZp Y2UgaG9uZXN0bHkgaGFzIGEgc2ltaWxhciBlbGVtZW50IGFzIHN1Yi1zaXRlcywgY29ycmVzcG9u ZGluZyB0byB2bGFuLCBidXQgd2Ugc3RpbGwgYWxsb3dzIG11bHRpcGxlIHZwbnMgYW5kIGJncCBw ZWVycywgZWFjaCBkaWZmZXJlbnQgdnBuIGFjY2VzcyBwZXIgcGVlciwgd2l0aGluIGEgc2luZ2xl IHZsYW4uDQoNCkFsbCB0aGUgYmVzdCwNCktlbmljaGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbQ0KU2VudDogRnJpZGF5LCBKYW51YXJ5 IDE1LCAyMDE2IDExOjMxIFBNDQpUbzogbDNzbUBpZXRmLm9yZw0KU3ViamVjdDogW0wzc21dIE1v ZGVsaW5nIGEgc2l0ZSB3aXRoIG11bHRpcGxlIHN1YnNpdGVzDQoNCltDcmVhdGluZyBhbm90aGVy IHRvcGljIGZvciBiZXR0ZXIgZm9sbG93dXBdDQoNCiANCg0KVG9kYXkgdGhlIG1vZGVsIGhhcyB0 aGUgYWJpbGl0eSB0byBjcmVhdGUgc2l0ZXMsIGEgc2l0ZSBjYW4gYmUgbXVsdGlob21lZCB0byB0 aGUgbmV0d29yayB0aGFua3MgdG8gdGhlIHNpdGUtbmV0d29yay1hY2Nlc3Mgc3ViLXRyZWUuDQoN CiANCg0KTm93IHRoZSBxdWVzdGlvbiBpcyBob3cgdG8gd2UgbW9kZWwgc3VjaCBzY2VuYXJpb3Mg Og0KDQogDQoNCmEpICAgICAgIlNVQlZQTiBjYXNlIiA6IFNpbmdsZSAicGh5c2ljYWwiIGFjY2Vz cyBiZXR3ZWVuIFNQIGFuZCBjdXN0b21lciwgYnV0IG11bHRpcGxlIHN1Yi1hY2Nlc3NlcyBvbiB0 b3AgKFZMQU4sIFBQUCBzZXNzaW9ucywgb3Igd2hhdGV2ZXIgLiksIGVhY2ggb25lIHBvaW50aW5n IHRvIGEgc3BlY2lmaWMgVlBOLiBJdCBpcyBleHBlY3RlZCBmb3IgdGhlIGN1c3RvbWVyIHRvIGVu c3VyZSBmbG93IHNlcGFyYXRpb24gKFZSRiBsaXRlLCBWTEFOcyAuKS4gSXQncyB0eXBpY2FsbHkg YSBiaWcgY29tcGFueSB3aXRoIGEgSHViIHNpdGUgdXNlZCB3aGVyZSBhZmZpbGlhdGVzIGhhdmUg ZGVkaWNhdGVkIHJlc291cmNlcyBpbiB0aGUgSHViIHNpdGUsIGFuZCBhZmZpbGlhdGVzIG11c3Qg bm90IHRhbGsgdG8gZWFjaCBvdGhlciBvciBldmVuIHNoYXJlIHJlc291cmNlcy4gTm90ZSB0aGF0 IEkgcHV0dGVkICJwaHlzaWNhbCIgYmV0d2VlbiBxdW90ZXMgYmVjYXVzZSBpdCBjYW4gYmUgYSBu ZXN0ZWQgbG9naWNhbCBhY2Nlc3NlcyAuDQoNCiANCg0KIA0KDQpiKSAgICAgICJJTlRFUi1BUyBv cHRpb24gQSBsaWtlICIgY2FzZSA6IHRoaXMgaXMgdGhlIGJhY2sgdG8gYmFjayBWUkYgY2FzZSwg YXMgcHJldmlvdXNseSBzaW5nbGUgInBoeXNpY2FsIiBhY2Nlc3MgYW5kIG11bHRpcGxlIGxvZ2lj YWwgYWNjZXNzZXMgb24gdG9wIGVhY2ggb25lIHBvaW50aW5nIHRvIGEgc2VwYXJhdGUgVlBOLiBJ IHB1dHRlZCBpbnRlckFTLCBidXQgdGhpcyBjYW4gYmUgImludHJhLUFTIiB3aXRoIGlCR1AgYmFj ayB0byBiYWNrIFZSRnMgYWxzbyAoaW50ZXJuYWwgREMgZm9yIGV4YW1wbGUpDQoNCiANCg0KYykg ICAgICAgV2hhdCBhYm91dCBvcHRpb24gQiA/IERvIHdlIGNvbnNpZGVyIG9wdGlvbiBCIGFzIGEg c2VydmljZSA/IEkgd291bGQgbm90IGJlIGluIGZhdm9yIG9mIHRoYXQuIE9wdGlvbiBCIHNldHVw cyBhcmUgcmVhbGx5IHBhcnRpY3VsYXIgaW4gdGVybSBvZiBkZXNpZ24sIHNlY3VyaXR5IC4gIFNv IEkgd291bGQgbGlrZSB0byBoYXZlIG9wdGlvbiBCIG91dCBvZiBzY29wZS4NCg0KIA0KDQogDQoN CkV2ZW4gaWYgYSkgYW5kIGIpIGFyZSBzZXBhcmF0ZWQgdXNlIGNhc2VzIGZyb20gYSBzZXJ2aWNl IHBvaW50IG9mIHZpZXcsIHRoZXNlIGFyZSBzaW1pbGFyIGluIHRlcm0gb2YgbW9kZWxpbmcuDQoN CiANCg0KVG9kYXkgd2UgY2FuIG1vZGVsIGl0IGhhcyBhIGNvbGxlY3Rpb24gb2Ygc2VwYXJhdGVk IHNpdGVzIHdpdGhvdXQgYW55IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGVhY2ggb3RoZXIuIFRoZSBv dGhlciBwb2ludCBpcyB0aGF0IHdlIGNhbm5vdCBleHByZXNzIGFueSAgcHJvcGVydHkgb2YgdGhl ICJwaHlzaWNhbCIgYXR0YWNobWVudCBidXQgdGhlcmUgbWF5IGZldyAoZW5jcnlwdGlvbiA/KS4g V2UgY2FuIGtlZXAgdGhlIG1vZGVsIGFzIGl0IGlzIHdpdGggdGhpcyBsaW1pdGF0aW9uIG9yIHdl IGNhbiBjcmVhdGUgc2l0ZSBhbmQgc3ViLXNpdGUgaGllcmFyY2h5IHdoaWNoIGFzIEkgYWxyZWFk eSBzYWlkIG1heSBjb21wbGV4aWZ5IHRoZSByZWFkaW5nIGFuZCB1c2FiaWxpdHkgKElNTykuDQoN Ckl0IG1heSBsb29rIGxpa2UgdGhpcyA6DQoNCiANCg0KoaQgICAgICAgICBTaXRlcw0KDQpvICAg U2l0ZS1vbmx5LXBhcmFtZXRlcnMgOg0KDQqh7CAgTG9jYXRpb24NCg0KoewgIERpdmVyc2l0eQ0K DQqh7CAgbWFuYWdlbWVudA0KDQqh7CAgU2VjdXJpdHkNCg0KbyAgIFNwZWNpZmljLXBhcmFtZXRl cnMgOiA8LSB0byBiZSB1c2VkIG9ubHkgaWYgdGhlcmUgaXMgbm8gc3Vic2l0ZS4NCg0KoewgIFZw bi1wb2xpY3kNCg0KoewgIFNlcnZpY2VzDQoNCqHsICBSb3V0aW5nLXByb3RvY29scw0KDQqh7CAg U2l0ZS1uZXR3b3JrLWFjY2Vzc2VzDQoNCqGkICAgICAgICAgLi4NCg0KbyAgIFN1Yi1zaXRlcyA6 IDwtIHRvIGJlIHVzZWQgaW4gY2FzZSBvZiBzdWIgc2l0ZXMgcHJlc2VudA0KDQqh7CAgU3BlY2lm aWMtcGFyYW1ldGVycyA6DQoNCqGkICAgICAgICAgVnBuLXBvbGljeQ0KDQqhpCAgICAgICAgIFNl cnZpY2VzDQoNCqGkICAgICAgICAgUm91dGluZy1wcm90b2NvbHMNCg0KoaQgICAgICAgICBTaXRl LW5ldHdvcmstYWNjZXNzZXMNCg0KbyAgIC4NCg0KIA0KDQpJJ20gYWxzbyB3b25kZXJpbmcgaWYg YmVhcmVyIHBhcmFtZXRlcnMgbXVzdCBhbHNvIGJlIHRha2VuIG91dCBpbiB0aGlzIGNhc2UgYW5k IHB1dHRlZCBpbiB0aGUgc2l0ZS1vbmx5LXBhcmFtZXRlcnMuIA0KDQpUaGUgaGllcmFyY2h5IGJl Y29tZXMgcmVhbGx5IGNvbXBsZXggaGVyZSBhbmQgSSB3b3VsZCBsaWtlIHRvIGtlZXAgaXQgYXMg c2ltcGxlIGFzIHBvc3NpYmxlLg0KDQogDQoNCiANCg0KV291bGQgYmUgZ29vZCB0byBoYXZlIG11 bHRpcGxlIGZlZWRiYWNrcyBmcm9tIHRoZSBXRyB0byBzZWUgd2hlcmUgdGhlIGNvbnNlbnN1cyBp cy4NCg0KIA0KDQogDQoNCk9yYW5nZSBsb2dvIDxodHRwOi8vd3d3Lm9yYW5nZS5jb20vPiANCg0K IA0KDQpTdGVwaGFuZSBMaXRrb3dza2kNCk5ldHdvcmsgQXJjaGl0ZWN0DQpPcmFuZ2UvU0NFL0VR VUFOVC9PSU5JUy9ORVQNCg0KT3JhbmdlIEV4cGVydCBGdXR1cmUgTmV0d29ya3MNCg0KcGhvbmU6 ICszMyAyIDIzIDI4IDQ5IDgzIDxodHRwczovL21vbnNpLnNzby5mcmFuY2V0ZWxlY29tLmZyL2lu ZGV4LmFzcD90YXJnZXQ9aHR0cCUzQSUyRiUyRmNsaWN2b2ljZS5zc28uZnJhbmNldGVsZWNvbS5m ciUyRkNsaWN2b2ljZVYyJTJGVG9vbEJhci5kbyUzRmFjdGlvbiUzRGRlZmF1bHQlMjZyb290c2Vy dmljZSUzRFNJR05BVFVSRSUyNnRvJTNEKzMzJTIwMiUyMDIzJTIwMjglMjA0OSUyMDgzJTIwPg0K bW9iaWxlOiArMzMgNiAzNyA4NiA5NyA1MiA8aHR0cHM6Ly9tb25zaS5zc28uZnJhbmNldGVsZWNv bS5mci9pbmRleC5hc3A/dGFyZ2V0PWh0dHAlM0ElMkYlMkZjbGljdm9pY2Uuc3NvLmZyYW5jZXRl bGVjb20uZnIlMkZDbGljdm9pY2VWMiUyRlRvb2xCYXIuZG8lM0ZhY3Rpb24lM0RkZWZhdWx0JTI2 cm9vdHNlcnZpY2UlM0RTSUdOQVRVUkUlMjZ0byUzRCszMyUyMDYlMjAzNyUyMDg2JTIwOTclMjA1 MiUyMD4NCnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIDxtYWlsdG86c3RlcGhhbmUubGl0 a293c2tpQG9yYW5nZS5jb20+ICANCg0KIA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlv dS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMM3NtIG1haWxpbmcgbGlzdA0KTDNzbUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMM3NtIG1haWxpbmcg bGlzdA0KTDNzbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9sM3NtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpMM3NtIG1haWxpbmcgbGlzdA0KTDNzbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sM3NtDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KTDNzbSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDNzbQ0KDQoNCg== From nobody Thu Feb 25 02:23:19 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23941A8A96 for ; Thu, 25 Feb 2016 02:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 rWkkvEieb-zt for ; Thu, 25 Feb 2016 02:23:13 -0800 (PST) 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 7F6DD1A0094 for ; Thu, 25 Feb 2016 02:23:13 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id D1E3AC012B; Thu, 25 Feb 2016 11:23:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id A4DBC1A0066; Thu, 25 Feb 2016 11:23:10 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0279.002; Thu, 25 Feb 2016 11:23:10 +0100 From: To: Aijun Wang <13301168517@189.cn>, "l3sm@ietf.org" Thread-Topic: [L3sm] Additional Issues---site's parameter relation with specific vpn Thread-Index: AdFvcZ2IgU8kJ02yRIulOO8e+OsH+QAA1zAwAAwbQJAAAELhgAAD/WVw Date: Thu, 25 Feb 2016 10:23:10 +0000 Message-ID: <20780_1456395790_56CED60E_20780_6939_1_9E32478DFA9976438E7A22F69B08FF92168CAD3B@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <005d01d16f75$1107ddc0$33179940$@cn> <8465_1456388619_56CEBA0B_8465_1437_1_9E32478DFA9976438E7A22F69B08FF92168CA7F9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <00ab01d16fa8$22d4df20$687e9d60$@cn> In-Reply-To: <00ab01d16fa8$22d4df20$687e9d60$@cn> 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: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92168CAD3BOPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Cc: "'Ogaki, Kenichi'" Subject: Re: [L3sm] Additional Issues---site's parameter relation with specific vpn X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 10:23:18 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92168CAD3BOPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Your statement is not true, in multiVPN, you have a single logical access. = The role per VPN is defined in vpn-policy and it works fine. From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 09:40 To: LITKOWSKI Stephane SCE/OINIS; l3sm@ietf.org Cc: 'Ogaki, Kenichi' Subject: Re: [L3sm] Additional Issues---site's parameter relation with spec= ific vpn Hi, What we are discussing here is when one site belong to multiple vpn, will t= he various site's attribute will be different or definitely same. For examp= le, one site may be hub-role in one vpn, but may be spoke-role in another v= pn, and the attributes "site-diversity","management","vpn-policy","maximum-= routes","security","service","routing-protocol","site-network-accesses" wil= l be different for hub/spoke site. Ogaki raised the similar issue for "site-network-accesses", please refer th= e thread https://mailarchive.ietf.org/arch/msg/l3sm/86TbWo1FUsKbzq9uocIv4Oh= _vfw and the following exchange mail. How do you solve this issue within the current Yang model? From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Thursday, February 25, 2016 4:24 PM To: Aijun Wang; l3sm@ietf.org Subject: RE: [L3sm] Additional Issues---site's parameter relation with spec= ific vpn Hi, Inline comments From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 03:34 To: l3sm@ietf.org Subject: [L3sm] Additional Issues---site's parameter relation with specific= vpn Hi, L3SMer: With the discussion about the current L3VPN yang model, we found there is a= nother additional issue needed to be solved. This issue will influence the = design of L3SM Yang structure as well. Issue description: In current L3VPN yang model, we define the site's variou= s parameters via several container, such as "location", "site-diversity","management","vpn-policy","maximum-rou= tes","security","service","routing-protocol","site-network-accesses" etc. F= or these containers, only the "location" is determined and has no relation = with the specific vpn id, other containers are all related with the specifi= c vpn id. That is to say, if the vpn is different, the "site-diversity","management",= "vpn-policy","maximum-routes","security","service","routing-protocol","site= -network-accesses" container will have different values, but in current Yan= g model, only the "vpn-policy" has relationship with the vpn-id. [SLI] I cannot agree, a multiVPN scenario strongly requires that each "VPN = attachment" as the same parameter this is by design because all the "VPN at= tachments" are using the same logical access. Only the vpn-policy plays wit= h the VPN attachment. I think you are confusing with subVPN where you have = a logical access per VPN with potential different parameters but this is a = different subject that is also under discussion. Solution proposal: Put the site definition or reference within the list "vp= n-svc", please see https://mailarchive.ietf.org/arch/msg/l3sm/lB4HbUVczwyyg= AScPeh4tV0EBRo So, what your consideration for this issue and solution proposal? Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network Research and Operation Support Department ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_9E32478DFA9976438E7A22F69B08FF92168CAD3BOPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Your = statement is not true, in multiVPN, you have a single logical access. The r= ole per VPN is defined in vpn-policy and it works fine.

=  

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Thursday, February 25, 2016 09:40
To: LITKOWSKI Stephane SCE/OINIS; l3sm@ietf.org
Cc: 'Ogaki, Kenichi'
Subject: Re: [L3sm] Additional Issues---site's parameter relation wi= th specific vpn

 =

Hi,

 

What we are discussing here is when one site belong to multiple vpn, w= ill the various site’s attribute will be different or definitely same= . For example, one site may be hub-role in one vpn, but may be spoke-role in another vpn, and the attributes <= span style=3D"mso-fareast-language:ZH-CN">“site-diversity”,R= 21;management”,”vpn-policy”,”maximum-routes”,= ”security”,”service”,”routing-protocol”= ,”site-network-accesses” will be different for hub/spoke site.  

Ogaki raised the similar issue for “site-network-accesses”= , please refer the thread https://mailarchive.ietf.org/arch/msg/l3sm/86TbWo1FUsKbzq9uocIv4Oh_vfw = and the following exchange mail.

 

How do you solve this issue within the current Yang model?<= /span>

 

 

From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
Sent: Thursday, February 25, 2016 4:24 PM
To: Aijun Wang; l3sm@ietf.org Subject: RE: [L3sm] Additional Issues---site's parameter relation wi= th specific vpn

 

Hi,

 

Inline comments

 

From: L3sm [mailto:l3sm-bounces@ietf.or= g] On Behalf Of Aijun Wang
Sent: Thursday, February 25, 2016 03:34
To: l3sm@ietf.org
Subject: [L3sm] Additional Issues---site's parameter relation with s= pecific vpn

 

Hi, L3SMe= r:

&nbs= p;

With the = discussion about the current L3VPN yang model, we found there is another ad= ditional issue needed to be solved. This issue will influence the design of= L3SM Yang structure as well.

&nbs= p;

Issue des= cription: In current L3VPN yang model, we define the site’s various p= arameters via several container,

such as “locationR= 21;, “site-diversity”,”management”,”vpn-polic= y”,”maximum-routes”,”security”,”service= ”,”routing-protocol”,”site-network-accesses” etc. For these containers, only the “location” is determined a= nd has no relation with the specific vpn id, other containers are all relat= ed with the specific vpn id.

That is to say, if the vpn = is different, the “site-diversity”,”management”,= 221;vpn-policy”,”maximum-routes”,”security”,&= #8221;service”,”routing-protocol”,”site-network-acc= esses” container will have different values, but in current Yang model, only the = “vpn-policy” has relationship with the vpn-id.

[SLI] I cannot agree, a multiVPN scenario strongly requires that each = “VPN attachment” as the same parameter this is by design becaus= e all the “VPN attachments” are using the same logical access. Only the vpn-policy plays with the VPN attachment. I think you are= confusing with subVPN where you have a logical access per VPN with potenti= al different parameters but this is a different subject that is also under = discussion.

 

 

Solution = proposal: Put the site definition or reference within the list “vpn-s= vc”, please see https://mailarchive.ietf.org/arch/msg/l3sm/lB4HbUVczwyygAScPeh4tV0EBRo<= o:p>

&nbs= p;

So, what = your consideration for this issue and solution proposal?<= /p>

&nbs= p;

Best Regards.

 

Aijun Wang

 

China Telecom Corporation Limit= ed Beijing Research Institute 

Network Research and Operation Support Departm= ent

&nbs= p;

___________________________=
___________________________________________________________________________=
___________________
 

Ce message et ses pieces jo=
intes peuvent contenir des informations confidentielles ou privilegiees et =
ne doivent donc


pas etre diffuses, exploite=
s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu=
illez le signaler


a l'expediteur et le detrui=
re ainsi que les pieces jointes. Les messages electroniques etant susceptib=
les d'alteration,


Orange decline toute respon=
sabilite si ce message a ete altere, deforme ou falsifie. Merci.=



 

This message and its attach=
ments may contain confidential or privileged information that may be protec=
ted by law;


they should not be distribu=
ted, used or copied without authorisation.


If you have received this e=
mail in error, please notify the sender and delete this message and its att=
achments.


As emails may be altered, O=
range is not liable for messages that have been modified, changed or falsif=
ied.


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.
--_000_9E32478DFA9976438E7A22F69B08FF92168CAD3BOPEXCLILMA4corp_-- From nobody Thu Feb 25 03:56:23 2016 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2491A1DBE for ; Thu, 25 Feb 2016 03:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.606 X-Spam-Level: X-Spam-Status: No, score=-5.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 NXsUwHrsHK34 for ; Thu, 25 Feb 2016 03:56:19 -0800 (PST) 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 37FAF1A1C06 for ; Thu, 25 Feb 2016 03:56:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJD64283; Thu, 25 Feb 2016 11:56:15 +0000 (GMT) Received: from LHREML706-CAH.china.huawei.com (10.201.5.182) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 11:56:13 +0000 Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 11:56:13 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 19:56:08 +0800 From: Qin Wu To: "l3sm@ietf.org" Thread-Topic: L3SM Virtual Interim reminder (8am EST, Thursday, February 25, 2015) Thread-Index: AQHRYdIJSEN0vTuDxk+xMTD8cRPr5588u+FQ Date: Thu, 25 Feb 2016 11:56:07 +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.208] Content-Type: multipart/mixed; boundary="_005_B8F9A780D330094D99AF023C5877DABA852C274Bnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010203.56CEEBE0.0048, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 96a8ba7c98e5b54956293d0a2bad7dfb Archived-At: Cc: "adrian@olddog.co.uk" Subject: [L3sm] L3SM Virtual Interim reminder (8am EST, Thursday, February 25, 2015) X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 11:56:21 -0000 --_005_B8F9A780D330094D99AF023C5877DABA852C274Bnkgeml513mbxchi_ Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA852C274Bnkgeml513mbxchi_" --_000_B8F9A780D330094D99AF023C5877DABA852C274Bnkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TDNTTSB2aXJ0dWFsIGludGVyaW0NCg0KVGh1cnNkYXksIEZlYnJ1YXJ5IDI1LCAyMDE1DQoNCjg6 MDAgYW0gRWFzdGVybiBTdGFuZGFyZCBUaW1lIChOZXcgWW9yaywgR01ULTA1OjAwKQ0KDQoNCg0K QWdlbmRhIGlzIGF2YWlsYWJsZSBhdA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv aW50ZXJpbS8yMDE2LzAyLzI1L2wzc20vYWdlbmRhL2FnZW5kYS1pbnRlcmltLTIwMTYtbDNzbS0x DQpUaGUgZGlzY3Vzc2lvbiBzbGlkZXMgY2FuIGJlIGZvdW5kIGF0IHRoZSBwcm9jZWVkaW5ncyBw YWdlDQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTYvMDIvMjUv bDNzbS9wcm9jZWVkaW5ncy5odG1sDQoNClFpbiAmIEFkcmlhbg0K5Y+R5Lu25Lq6OiBMM3NtIFtt YWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggTDNTTSBXb3JraW5nIEdyb3VwDQrl j5HpgIHml7bpl7Q6IDIwMTblubQy5pyIOOaXpSAyOjA1DQrmlLbku7bkuro6IGwzc21AaWV0Zi5v cmcNCuS4u+mimDogW0wzc21dIFdlYkV4IG1lZXRpbmcgaW52aXRhdGlvbjogTDNTTSBWaXJ0dWFs IEludGVyaW0NCg0KSGVsbG8sDQoNCkwzU00gV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBq b2luIHRoaXMgV2ViRXggbWVldGluZy4NCg0KDQoNCg0KDQpMM1NNIFZpcnR1YWwgSW50ZXJpbQ0K DQpUaHVyc2RheSwgRmVicnVhcnkgMjUsIDIwMTYNCg0KODowMCBhbSAgfCAgRWFzdGVybiBTdGFu ZGFyZCBUaW1lIChOZXcgWW9yaywgR01ULTA1OjAwKSAgfCAgMiBocnMNCg0KDQoNCg0KDQpKb2lu IFdlYkV4IG1lZXRpbmcgPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1l NDk0NGM3N2E1OGEzZDk5YzQyMGI4ZWE4YjI3NTJlYj4NCg0KDQpNZWV0aW5nIG51bWJlcjoNCg0K NjQxIDQyMSA0MzgNCg0KTWVldGluZyBwYXNzd29yZDoNCg0KMTIzNA0KDQoNCg0KDQoNCkpvaW4g YnkgcGhvbmUNCg0KMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D YW5hZGEpDQoNCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkN Cg0KQWNjZXNzIGNvZGU6IDY0MSA0MjEgNDM4DQoNClRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0 aW9uczxodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZj4N Cg0KDQoNCg0KDQpBZGQgdGhpcyBtZWV0aW5nPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW02Yjk2MWNjYjc5YzNjNDllMmM3ZjVhYTI2ZjI2NDQzNz4gdG8geW91ciBjYWxl bmRhci4gKENhbm5vdCBhZGQgZnJvbSBtb2JpbGUgZGV2aWNlcy4pDQoNCg0KDQoNCg0KQ2FuJ3Qg am9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0LjxodHRwczovL2lldGYud2ViZXguY29t L2lldGYvbWM+DQoNCg0KDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0 aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50 IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVy YWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRv bWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNl bnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0 IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLg0KDQoNCg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA852C274Bnkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojNjY2NjY2 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojNjY2NjY2Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4 dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQ2hhcg0KCXttc28t c3R5bGUtbmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgt Q04iIGxpbms9IiM2NjY2NjYiIHZsaW5rPSIjNjY2NjY2Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+TDNTTSB2 aXJ0dWFsIGludGVyaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGh1cnNkYXksIEZlYnJ1YXJ5IDI1LCAyMDE1PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPjg6MDAgYW0gRWFzdGVybiBTdGFuZGFyZCBUaW1lIChOZXcgWW9yaywgR01ULTA1OjAwKQ0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5BZ2VuZGEgaXMgYXZhaWxhYmxlIGF0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvaW50ZXJpbS8yMDE2LzAyLzI1L2wzc20vYWdlbmRhL2FnZW5kYS1pbnRlcmltLTIwMTYt bDNzbS0xIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTYvMDIv MjUvbDNzbS9hZ2VuZGEvYWdlbmRhLWludGVyaW0tMjAxNi1sM3NtLTE8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+VGhlIGRpc2N1c3Npb24gc2xpZGVzIGNhbiBiZSBmb3VuZCBhdCB0 aGUgcHJvY2VlZGluZ3MgcGFnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wMi8yNS9sM3Nt L3Byb2NlZWRpbmdzLmh0bWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzL2ludGVyaW0vMjAxNi8wMi8yNS9sM3NtL3Byb2NlZWRpbmdzLmh0bWw8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UWluICZhbXA7IEFk cmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBMM3NtIFttYWlsdG86bDNzbS1i b3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPkwzU00gV29ya2luZyBHcm91cDxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDE2 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1V UyI+Mjwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+ODwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJF Ti1VUyI+IDI6MDU8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gbDNzbUBpZXRmLm9yZzxicj4NCjwvc3Bhbj48 Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBbTDNzbV0gV2ViRXggbWVldGluZyBpbnZpdGF0aW9uOiBMM1NNIFZpcnR1YWwgSW50ZXJpbTxv OnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBz dHlsZT0icGFkZGluZzozLjc1cHQgMGNtIDBjbSAwY20iPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSI1 MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdDttYXJnaW4tbGVmdDozLjc1cHQiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0K PHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIg d2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBz dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzRENEQ0RCI+SGVsbG8sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3Rk Pg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzo3LjVwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNEQ0RDREIj5MM1NNIFdvcmtpbmcg R3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYkV4IG1lZXRpbmcuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRl cj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+ DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i MCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRk IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzRENEQ0RCI+TDNTTSBWaXJ0dWFsIEludGVyaW08L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNEQ0RDREIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij5UaHVyc2RheSwgRmVicnVhcnkgMjUs IDIwMTYNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNjY2NjY2Ij44OjAwIGFtJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwO0Vhc3Rl cm4gU3RhbmRhcmQgVGltZSAoTmV3IFlvcmssIEdNVC0wNTowMCkmbmJzcDsmbmJzcDt8Jm5ic3A7 Jm5ic3A7MiBocnMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2 O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIg c3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBw dCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBi b3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0 aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNt IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBBRkY5Ij48YSBocmVmPSJodHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZTQ5NDRjNzdhNThhM2Q5OWM0MjBi OGVhOGIyNzUyZWIiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlv bjpub25lIj5Kb2luDQogV2ViRXggbWVldGluZzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPiA8L3NwYW4+DQo8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRv IWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDMuNzVw dCAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2NjYi Pk1lZXRpbmcgbnVtYmVyOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHls ZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzY2NjY2NiI+NjQxIDQyMSA0MzgNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAzLjc1cHQgMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij5NZWV0aW5nIHBh c3N3b3JkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6 MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2 NjY2NjYiPjEyMzQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2Njtk aXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0i TXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0 eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQi Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2NjYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0 Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2NjYiPkpvaW4gYnkgcGhvbmU8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2NiI+MS04Nzct NjY4LTQ0OTM8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM2NjY2NjYiPiZuYnNwO0NhbGwtaW4NCiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5h ZGEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM2NjY2NjYiPjEtNjUwLTQ3OS0zMjA4PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij4mbmJzcDtDYWxsLWluDQog dG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90 cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2NiI+QWNjZXNzIGNvZGU6Jm5ic3A7NjQx IDQyMSA0Mzg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBz dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzY2NjY2NiI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3Rv bGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlRvbGwtZnJlZQ0KIGNhbGxpbmcgcmVz dHJpY3Rpb25zPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdo dDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2NjYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9u ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxU YWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRo OjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2NiI+PGEg aHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTZiOTYxY2NiNzlj M2M0OWUyYzdmNWFhMjZmMjY0NDM3Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRl Y29yYXRpb246bm9uZSI+QWRkDQogdGhpcyBtZWV0aW5nPC9zcGFuPjwvYT4gdG8geW91ciBjYWxl bmRhci4gKENhbm5vdCBhZGQgZnJvbSBtb2JpbGUgZGV2aWNlcy4pPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl bGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5 Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY207aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM2NjY2NjYiPkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/DQo8YSBocmVmPSJodHRwczov L2lldGYud2ViZXguY29tL2lldGYvbWMiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQt ZGVjb3JhdGlvbjpub25lIj5Db250YWN0IHN1cHBvcnQuPC9zcGFuPjwvYT4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4N Cjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjcuNXB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY207aGVpZ2h0OjcuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbGluZS1oZWlnaHQtYWx0OjcuNXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRp bmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6I0EwQTBBMCI+SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUg dGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlv biBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZQ0KIHJlY29yZGVkLCB3aGljaCBtYXkgYmUg ZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwg eW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBu b3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGgg dGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA852C274Bnkgeml513mbxchi_-- --_005_B8F9A780D330094D99AF023C5877DABA852C274Bnkgeml513mbxchi_ Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=3801; creation-date="Sun, 07 Feb 2016 18:04:50 GMT"; modification-date="Sun, 07 Feb 2016 18:04:50 GMT" Content-ID: <042C784BE2B0C242A67358DE858EC52C@huawei.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE0MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE0MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86bDNzbUBpZXRmLm9yZwpPUkdBTklaRVI7Q049Ikwz U00gV29ya2luZyBHcm91cCI6TUFJTFRPOmwzc20tY2hhaXJzQGlldGYub3JnCkRUU1RBUlQ7VFpJ RD0iRWFzdGVybiBUaW1lIjoyMDE2MDIyNVQwODAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVybiBUaW1l IjoyMDE2MDIyNVQxMDAwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmClRS QU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQ1NDg2ODI3MgpVSUQ6MGNmZmEzOTMtMjIwOC00MDM4LTkx ZmItYzdmOTlhZDc3ZDYzCkRUU1RBTVA6MjAxNjAyMjVUMTMwMDAwWgpERVNDUklQVElPTjpcblxu XG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW02NzY5ZTQ1MjI1N2FjM2YwNDZlYmNiNWYzNTgwYTg2YlxuTWVldGluZyBudW1iZXI6IDY0 MSA0MjEgNDM4XG5NZWV0aW5nIHBhc3N3b3JkOiAxMjM0XG5cblxuSk9JTiBCWSBQSE9ORVxuMS04 NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIFxuMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuQWNjZXNzIGNvZGU6IDY0 MSA0MjEgNDM4XG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogXG5odHRwOi8vd3d3 LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2FuJ3Qgam9p biB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMg V2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVy aW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxl IGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRp Y2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0 byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3Ig ZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDoJ PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZPTlQgU0laRT0iNCIgRkFD RT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW02NzY5ZTQ1MjI1N2FjM2YwNDZlYmNiNWYzNTgwYTg2YiI+PEZPTlQgU0laRT0iMyIg Q09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1lZXRpbmc8L0ZPTlQ+PC9h PgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05UPgkJCQkJPC90ZD4JCQkJ CTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjY0 MSA0MjEgNDM4PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0YWJsZT48 dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGlu ZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+MTIzNDwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4JCTwvRk9OVD48Rk9O VCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+PEZPTlQg U0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTg3Ny02NjgtNDQ5Mzwvc3Ryb25n PiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsg PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4x LTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPkFjY2VzcyBjb2RlOiA2NDEgNDIxIDQzODwvRk9OVD4mbmJzcDsgPEJSPjxhIGhyZWY9 Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIj48Rk9O VCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPlRvbGwtZnJlZSBjYWxsaW5n IHJlc3RyaWN0aW9uczwvRk9OVD48L2E+ICZuYnNwOyA8QlI+PC9GT05UPjxCUj48QlI+CSZuYnNw OzxCUj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj4JCQkJQ2Fu J3Qgam9pbiB0aGUgbWVldGluZz88L0ZPTlQ+CTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9tYyI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+ Q29udGFjdCBzdXBwb3J0LjwvRk9OVD48L2E+CSZuYnNwOzxCUj4mbmJzcDs8QlI+PEZPTlQgQ09M T1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVh c2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBt YXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vz c2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlv dSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5z IHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPC9GT05UPjwvRk9OVD4K U1VNTUFSWTpMM1NNIFZpcnR1YWwgSW50ZXJpbQpQUklPUklUWTo1CkNMQVNTOlBVQkxJQwpCRUdJ TjpWQUxBUk0KVFJJR0dFUjotUFQxNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJT046UmVtaW5k ZXIKRU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK --_005_B8F9A780D330094D99AF023C5877DABA852C274Bnkgeml513mbxchi_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Sun, 07 Feb 2016 18:04:50 GMT"; modification-date="Sun, 07 Feb 2016 18:04:50 GMT" Content-ID: <1EF21D918251AE479549E67AAF9919EC@huawei.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkwzc20gbWFp bGluZyBsaXN0DQpMM3NtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2wzc20NCg== --_005_B8F9A780D330094D99AF023C5877DABA852C274Bnkgeml513mbxchi_-- From nobody Thu Feb 25 05:07:54 2016 Return-Path: <13301168517@189.cn> X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1411A92F1 for ; Thu, 25 Feb 2016 05:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.507 X-Spam-Level: X-Spam-Status: No, score=0.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, FROM_LOCAL_DIGITS=0.001, FROM_LOCAL_HEX=0.006, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 qU-Rm_QyCQ_t for ; Thu, 25 Feb 2016 05:07:47 -0800 (PST) Received: from 189.cn (mta.189.cn [121.14.53.138]) by ietfa.amsl.com (Postfix) with ESMTP id 14C1D1A92EA for ; Thu, 25 Feb 2016 05:07:41 -0800 (PST) HMM_SOURCE_IP: 10.64.8.34:41009.741999686 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-114.248.174.69 (unknown [10.64.8.34]) by 189.cn (HERMES) with ESMTP id 2C4AD15C077; Thu, 25 Feb 2016 21:07:03 +0800 (CST) Received: from ip<114.248.174.69> ([10.53.61.90]) by zm-as4(MEDUSA 0.0.0.0) with ESMTP id ec492cf9-6300-4b58-aab5-216eb7e1336e for ke-oogaki@kddi.com; Thu Feb 25 21:07:19 2016 0/X-Total-Score: 0: X-FILTER-SCORE: to=<8c864e909088828c8a618c85858a4f84908e>, score=<14564056398HHHHHPHHdHHtHPdt3nvBoTXXXXXPXXIXXyXPIyZ4dhk> X-REAL-FROM: 13301168517@189.cn X-Receive-IP: 10.53.61.90 From: "Aijun Wang" <13301168517@189.cn> To: , References: <005d01d16f75$1107ddc0$33179940$@cn> <8465_1456388619_56CEBA0B_8465_1437_1_9E32478DFA9976438E7A22F69B08FF92168CA7F9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <00ab01d16fa8$22d4df20$687e9d60$@cn> <20780_1456395790_56CED60E_20780_6939_1_9E32478DFA9976438E7A22F69B08FF92168CAD3B@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <20780_1456395790_56CED60E_20780_6939_1_9E32478DFA9976438E7A22F69B08FF92168CAD3B@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Date: Thu, 25 Feb 2016 21:07:20 +0800 Message-ID: <002101d16fcd$7fa47c40$7eed74c0$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01D17010.8DC7BC40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdFvcZ2IgU8kJ02yRIulOO8e+OsH+QAA1zAwAAwbQJAAAELhgAAD/WVwAAW/RBA= Content-Language: zh-cn Archived-At: Cc: "'Ogaki, Kenichi'" Subject: Re: [L3sm] Additional Issues---site's parameter relation with specific vpn X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 13:07:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01D17010.8DC7BC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I discussed not only the role of the site. From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Thursday, February 25, 2016 6:23 PM To: Aijun Wang; l3sm@ietf.org Cc: 'Ogaki, Kenichi' Subject: RE: [L3sm] Additional Issues---site's parameter relation with specific vpn Your statement is not true, in multiVPN, you have a single logical access. The role per VPN is defined in vpn-policy and it works fine. From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 09:40 To: LITKOWSKI Stephane SCE/OINIS; l3sm@ietf.org Cc: 'Ogaki, Kenichi' Subject: Re: [L3sm] Additional Issues---site's parameter relation with specific vpn Hi, What we are discussing here is when one site belong to multiple vpn, will the various site's attribute will be different or definitely same. For example, one site may be hub-role in one vpn, but may be spoke-role in another vpn, and the attributes "site-diversity","management","vpn-policy","maximum-routes","security","serv ice","routing-protocol","site-network-accesses" will be different for hub/spoke site. Ogaki raised the similar issue for "site-network-accesses", please refer the thread https://mailarchive.ietf.org/arch/msg/l3sm/86TbWo1FUsKbzq9uocIv4Oh_vfw and the following exchange mail. How do you solve this issue within the current Yang model? From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Thursday, February 25, 2016 4:24 PM To: Aijun Wang; l3sm@ietf.org Subject: RE: [L3sm] Additional Issues---site's parameter relation with specific vpn Hi, Inline comments From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, February 25, 2016 03:34 To: l3sm@ietf.org Subject: [L3sm] Additional Issues---site's parameter relation with specific vpn Hi, L3SMer: With the discussion about the current L3VPN yang model, we found there is another additional issue needed to be solved. This issue will influence the design of L3SM Yang structure as well. Issue description: In current L3VPN yang model, we define the site's various parameters via several container, such as "location", "site-diversity","management","vpn-policy","maximum-routes","security","serv ice","routing-protocol","site-network-accesses" etc. For these containers, only the "location" is determined and has no relation with the specific vpn id, other containers are all related with the specific vpn id. That is to say, if the vpn is different, the "site-diversity","management","vpn-policy","maximum-routes","security","serv ice","routing-protocol","site-network-accesses" container will have different values, but in current Yang model, only the "vpn-policy" has relationship with the vpn-id. [SLI] I cannot agree, a multiVPN scenario strongly requires that each "VPN attachment" as the same parameter this is by design because all the "VPN attachments" are using the same logical access. Only the vpn-policy plays with the VPN attachment. I think you are confusing with subVPN where you have a logical access per VPN with potential different parameters but this is a different subject that is also under discussion. Solution proposal: Put the site definition or reference within the list "vpn-svc", please see https://mailarchive.ietf.org/arch/msg/l3sm/lB4HbUVczwyygAScPeh4tV0EBRo So, what your consideration for this issue and solution proposal? Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Network Research and Operation Support Department ____________________________________________________________________________ _____________________________________________ 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. ------=_NextPart_000_0022_01D17010.8DC7BC40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I discussed not only the role of the = site.

 

From:= = stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] =
Sent: Thursday, February 25, 2016 6:23 PM
To: Aijun = Wang; l3sm@ietf.org
Cc: 'Ogaki, Kenichi'
Subject: = RE: [L3sm] Additional Issues---site's parameter relation with specific = vpn

 

Your statement is = not true, in multiVPN, you have a single logical access. The role per = VPN is defined in vpn-policy and it works fine.

 

From:= L3sm [mailto:l3sm-bounces@ietf.org] = On Behalf Of Aijun Wang
Sent: Thursday, February 25, = 2016 09:40
To: LITKOWSKI Stephane SCE/OINIS; l3sm@ietf.org
Cc: 'Ogaki, = Kenichi'
Subject: Re: [L3sm] Additional Issues---site's = parameter relation with specific vpn

 

Hi,

 

What we are = discussing here is when one site belong to multiple vpn, will the = various site’s attribute will be different or definitely same. For = example, one site may be hub-role in one vpn, but may be spoke-role in = another vpn, and the attributes “site-diversity”,”management”,”= ;vpn-policy”,”maximum-routes”,”security”,&#= 8221;service”,”routing-protocol”,”site-network-ac= cesses” will be different for = hub/spoke site.  

Ogaki = raised the similar issue for “site-network-accesses”, please = refer the thread https://mailarchive.ietf.org/arch/msg/l3sm/86TbWo1FUsKbzq9uocIv4Oh= _vfw and the following exchange mail.

 

How do you = solve this issue within the current Yang model?

 

 

From:= stephane.litkowski@orange.c= om [mailto:stephane.litkowski@o= range.com]
Sent: Thursday, February 25, 2016 4:24 = PM
To: Aijun Wang; l3sm@ietf.org
Subject: RE: = [L3sm] Additional Issues---site's parameter relation with specific = vpn

 

Hi,

 

Inline = comments

 

From:= L3sm [mailto:l3sm-bounces@ietf.org] = On Behalf Of Aijun Wang
Sent: Thursday, February 25, = 2016 03:34
To: l3sm@ietf.org
Subject: = [L3sm] Additional Issues---site's parameter relation with specific = vpn

 

Hi, L3SMer:

 

With the discussion about the current L3VPN yang model, we = found there is another additional issue needed to be solved. This issue = will influence the design of L3SM Yang structure as = well.

 

Issue description: In current L3VPN yang model, we define = the site’s various parameters via several = container,

such as “location”, = “site-diversity”,”management”,”vpn-policy&#= 8221;,”maximum-routes”,”security”,”service&= #8221;,”routing-protocol”,”site-network-accesses”= etc. For these containers, only the “location” is = determined and has no relation with the specific vpn id, other = containers are all related with the specific vpn = id.

That is to say, if the vpn is different, the = “site-diversity”,”management”,”vpn-policy&#= 8221;,”maximum-routes”,”security”,”service&= #8221;,”routing-protocol”,”site-network-accesses”= container will have different values, but in current Yang model, only = the “vpn-policy” has relationship with the = vpn-id.

[SLI] I cannot agree, a multiVPN scenario = strongly requires that each “VPN attachment” as the same = parameter this is by design because all the “VPN = attachments” are using the same logical access. Only the = vpn-policy plays with the VPN attachment. I think you are confusing with = subVPN where you have a logical access per VPN with potential different = parameters but this is a different subject that is also under = discussion.

 

 

Solution proposal: Put the site = definition or reference within the list “vpn-svc”, please = see https://mailarchive.ietf.org/arch/msg/l3sm/lB4HbUVczwyygAScPeh4tV0= EBRo

 

So, what your consideration for this issue and solution = proposal?

 

Best = Regards.

 =

Aijun = Wang

 =

China = Telecom Corporation Limited Beijing Research Ins= titute 

Network = Research and Operation Support Department

 

___________________________________________________________________=
______________________________________________________<=
/pre>
 
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.
___________________________________________________________________=
______________________________________________________<=
/pre>
 
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.

------=_NextPart_000_0022_01D17010.8DC7BC40--


From nobody Thu Feb 25 07:59:36 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4341F1B2B73 for ; Thu, 25 Feb 2016 07:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level: 
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 dyWrWrtidOdG for ; Thu, 25 Feb 2016 07:59:33 -0800 (PST)
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 409511B2B63 for ; Thu, 25 Feb 2016 07:59:32 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJD95633; Thu, 25 Feb 2016 15:59:29 +0000 (GMT)
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 15:59:29 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 07:59:27 -0800
From: Lucy yong 
To: "l3sm@ietf.org" 
Thread-Topic: L3 service model suggestion
Thread-Index: AdFv5NXohY58UF8wRLqEAwIfFWnLNA==
Date: Thu, 25 Feb 2016 15:59:26 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57245D3B@dfweml701-chm>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.135.10]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D57245D3Bdfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56CF24E2.0093, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 86d98b1bee9a9fd65910e3dfed7833ac
Archived-At: 
Subject: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2016 15:59:35 -0000

--_000_2691CE0099834E4A9C5044EEC662BB9D57245D3Bdfweml701chm_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

Current L3vpn service model (the draft) specifies vpn-svc and site containe=
rs only. In order to address multiple vpn at one site, we need vpn-svc per =
site container too. Some attributes under site container should belong to v=
pn-svc per site container such as vpn-policy, service, etc. The site contai=
ner needs to have a parameter "multiplexing" to indicate if a site will hav=
e single vpn or multiple vpn. This will address the issue of multi-vpn at a=
 site discussed in today's interim meeting.

Not sure why need site-template container.

Regards,
Lucy

--_000_2691CE0099834E4A9C5044EEC662BB9D57245D3Bdfweml701chm_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi All,


 


Current L3vpn service model (the draft) specifies vp=
n-svc and site containers only. In order to address multiple vpn at one sit=
e, we need vpn-svc per site container too. Some attributes under site conta=
iner should belong to vpn-svc per
 site container such as vpn-policy, service, etc. The site container needs =
to have a parameter “multiplexing” to indicate if a site will h=
ave single vpn or multiple vpn. This will address the issue of multi-vpn at=
 a site discussed in today’s interim meeting.


 


Not sure why need site-template container.


 


Regards,


Lucy






--_000_2691CE0099834E4A9C5044EEC662BB9D57245D3Bdfweml701chm_--


From nobody Thu Feb 25 17:22:20 2016
Return-Path: <13301168517@189.cn>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F78B1A1A4C for ; Thu, 25 Feb 2016 17:22:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.854
X-Spam-Level: 
X-Spam-Status: No, score=0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_LOCAL_DIGITS=0.001, FROM_LOCAL_HEX=0.006, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_BL_SPAMCOP_NET=1.347, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 cb_9siGEoB1c for ; Thu, 25 Feb 2016 17:22:14 -0800 (PST)
Received: from 189.cn (ptr.189.cn [121.14.53.131]) by ietfa.amsl.com (Postfix) with ESMTP id AF5A01A1A48 for ; Thu, 25 Feb 2016 17:22:09 -0800 (PST)
HMM_SOURCE_IP: 10.64.8.34:57083.1915606097
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-219.142.69.77 (unknown [10.64.8.34]) by 189.cn (HERMES) with ESMTP id 56ABA2900D5; Fri, 26 Feb 2016 09:21:58 +0800 (CST)
Received: from ctbriwangaij ([219.142.69.77]) by zm-as4(MEDUSA 0.0.0.0) with ESMTP id af2d6189-06d0-4917-accf-12d9c448e65c for l3sm@ietf.org; Fri Feb 26 09:22:07 2016
0/X-Total-Score: 0:
X-FILTER-SCORE: to=<8d54948e618a8695874f909388>, score=<1456449727MMMMXMMxMMnMXxnJZls8kMjjjTjj2jjEjT2EOfcJ/ujj> 
X-REAL-FROM: 13301168517@189.cn
X-Receive-IP: 219.142.69.77
From: "Aijun Wang" <13301168517@189.cn>
To: "'Lucy yong'" , 
Date: Fri, 26 Feb 2016 09:22:15 +0800
Message-ID: <005001d17034$26bb1460$74313d20$@cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01D17077.34DE5460"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdFv5NXohY58UF8wRLqEAwIfFWnLNAATWkdgAABwt9A=
Content-Language: zh-cn
Archived-At: 
Subject: [L3sm]  L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2016 01:22:18 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0051_01D17077.34DE5460
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi, Lucy:

 

Is it more clear to put the list site within the list vpn-svc? This
correlate naturally the relationship between vpn id and its associated
sites, and also the attributes of these sites.

For site that belong to multiple vpn, the site' information will be existed
in several specific vpn context. Considering the site's attribute may be
vary for different vpn, it is reasonable for the customer.

 

For site-template container, I propose:

1.  we change it into grouping site-template, and use it within list sites,
or

2. define the related items directly  within the list sites and eliminate
the site-template container.

 

Best Regards.

 

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, February 25, 2016 11:59 PM
To: l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

 

Hi All,

 

Current L3vpn service model (the draft) specifies vpn-svc and site
containers only. In order to address multiple vpn at one site, we need
vpn-svc per site container too. Some attributes under site container should
belong to vpn-svc per site container such as vpn-policy, service, etc. The
site container needs to have a parameter "multiplexing" to indicate if a
site will have single vpn or multiple vpn. This will address the issue of
multi-vpn at a site discussed in today's interim meeting.

 

Not sure why need site-template container.

 

Regards,

Lucy


------=_NextPart_000_0051_01D17077.34DE5460
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi, =
Lucy:
 
Is it more clear to put the =
list site within the list vpn-svc? This correlate naturally the =
relationship between vpn id and its associated sites, and also the =
attributes of these sites.
For site that belong to =
multiple vpn, the site’ information will be existed in several =
specific vpn context. Considering the site’s attribute may be vary =
for different vpn, it is reasonable for the =
customer.
 
For site-template container, I =
propose:
1.  we change it into =
grouping site-template, and use it within list sites, =
or
2. define the related items =
directly  within the list sites and eliminate the site-template =
container.
 
Best =
Regards.
 
From:=
 L3sm [mailto:l3sm-bounces@ietf.org] =
On Behalf Of Lucy yong
Sent: Thursday, February 25, =
2016 11:59 PM
To: l3sm@ietf.org
Subject: =
[L3sm] L3 service model suggestion
 
Hi All,
 
Current L3vpn service model (the =
draft) specifies vpn-svc and site containers only. In order to address =
multiple vpn at one site, we need vpn-svc per site container too. Some =
attributes under site container should belong to vpn-svc per site =
container such as vpn-policy, service, etc. The site container needs to =
have a parameter “multiplexing” to indicate if a site will =
have single vpn or multiple vpn. This will address the issue of =
multi-vpn at a site discussed in today’s interim =
meeting.
 
Not sure why need site-template =
container.
 
Regards,
Lucy

------=_NextPart_000_0051_01D17077.34DE5460--


From nobody Thu Feb 25 17:53:36 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0091A1BDA for ; Thu, 25 Feb 2016 17:53:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.605
X-Spam-Level: 
X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham
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 C5dNA_030tp2 for ; Thu, 25 Feb 2016 17:53:31 -0800 (PST)
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 8E9911A1BD4 for ; Thu, 25 Feb 2016 17:53:30 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJE36039; Fri, 26 Feb 2016 01:53:28 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Feb 2016 01:53:27 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 26 Feb 2016 09:53:24 +0800
From: Qin Wu 
To: "l3sm@ietf.org" 
Thread-Topic: L3SM WG 2nd interim meeting minutes ( (8am EST, Thursday, February 25, 2015))
Thread-Index: AdEYn6sa4TVIhCl5R2aqZCZurw4pUhXlKlyQ
Date: Fri, 26 Feb 2016 01:53:23 +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.208]
Content-Type: multipart/mixed; boundary="_004_B8F9A780D330094D99AF023C5877DABA852C2C15nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.56CFB018.00A6, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c483371179300da30d787042a344249e
Archived-At: 
Cc: "adrian@olddog.co.uk" 
Subject: [L3sm] L3SM WG 2nd interim meeting minutes ( (8am EST, Thursday, February 25, 2015))
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2016 01:53:34 -0000

--_004_B8F9A780D330094D99AF023C5877DABA852C2C15nkgeml513mbxchi_
Content-Type: multipart/alternative;
	boundary="_000_B8F9A780D330094D99AF023C5877DABA852C2C15nkgeml513mbxchi_"

--_000_B8F9A780D330094D99AF023C5877DABA852C2C15nkgeml513mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all:



Attached is the initial version of draft minutes for Thursday L3SM interim =
meeting.

Please read them, and let us know if there is any corrections which are nee=
ded.



Qin and Adrian



--_000_B8F9A780D330094D99AF023C5877DABA852C2C15nkgeml513mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all:

 


Attached is the initial vers=
ion of draft minutes for Thursday L3SM interim meeting.

Please read them, and let us=
 know if there is any corrections which are needed.


 


Qin and Adrian


 


 






--_000_B8F9A780D330094D99AF023C5877DABA852C2C15nkgeml513mbxchi_--

--_004_B8F9A780D330094D99AF023C5877DABA852C2C15nkgeml513mbxchi_
Content-Type: text/plain; name="L3SM-minutes-2016.txt"
Content-Description: L3SM-minutes-2016.txt
Content-Disposition: attachment; filename="L3SM-minutes-2016.txt"; size=8326;
	creation-date="Thu, 25 Feb 2016 15:01:48 GMT";
	modification-date="Thu, 25 Feb 2016 15:10:52 GMT"
Content-Transfer-Encoding: base64

VmlydHVhbCBCbHVlIFNoZWV0DQoNCkxheWVyIDMgVlBOIFNlcnZpY2UgTW9kZWwgV29ya2luZyBH
cm91cA0KDQpWaXJ0dWFsIEludGVyaW0gTWVldGluZyAyNXRoIEZlYnJ1YXJ5IDIwMTYgOiAxcG0g
TG9uZG9uDQoNCk5hbWUgICAgICAgICAgICAgICAgICBBZmZpbGlhdGlvbg0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpRaW4gV3UgICAgICAgICAgICAgICAg
SHVhd2VpDQpBZHJpYW4gRmFycmVsICAgICAgICAgT2xkIERvZyBDb25zdWx0aW5nDQpTdGVwaGFu
ZSBMaXRrb3dza2kgICAgT3JhbmdlDQpMdWlzIFRvbW90YWtpICAgICAgICAgVmVyaXpvbg0KTWlj
aGFlbCBTY2hhcmYgICAgICAgIEFsY2F0ZWwtTHVjZW50DQpEYW5pZWwgS2luZyAgICAgICAgICAg
VW5pdmVyc2l0eSBvZiBMYW5jYXN0ZXINCktlbmljaGkgT2dha2kgICAgICAgICBLRERJDQpCZW5v
aXQgQ2xhaXNlICAgICAgICAgQ2lzY28NCkFpanVuIFdhbmcgICAgICAgICAgICBDaGluYSBUZWxl
Y29tDQpBbmggTGUgICAgICAgICAgICAgICAgTmV0Y3JhY2tlcg0KRGFuIFJvbWFzY2FudSAgICAg
ICAgIEF2YXlhDQpMdWN5IFlvbmcgICAgICAgICAgICAgSHVhd2VpDQpBbmRyZXcgVmVpdGNoICAg
ICAgICAgTmV0Q3JhY2tlcg0KDQoNCg0KDQoNCg0KDQpMYXllciAzIFZQTiBTZXJ2aWNlIE1vZGVs
IFdvcmtpbmcgR3JvdXANCg0KVmlydHVhbCBJbnRlcmltIE1lZXRpbmcgMjV0aCBGZWJydWFyeSAy
MDE2IDogMXBtIExvbmRvbg0KDQpNZWV0aW5nIE5vdGVzDQoNCkNoYWlyczoNCiAgICBRaW4gV3UN
CiAgICBBZHJpYW4gRmFycmVsDQogICAgDQoNCldlYmV4OiBodHRwczovL2lldGYud2ViZXguY29t
L2lldGYvai5waHA/TVRJRD1tZTQ5NDRjNzdhNThhM2Q5OWM0MjBiOGVhOGIyNzUyZWINCg0KTWVl
dGluZyBtYXRlcmlhbHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0v
MjAxNi8wMi8yNS9sM3NtL3Byb2NlZWRpbmdzLmh0bWwNCg0KSmFiYmVyOiBsM3NtQGphYmJlci5p
ZXQub3JnDQoNCkJsdWUgc2hlZXQ6IGh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAw
L3AvbDNzbS1pbnRlcmltLTIwMTYtMDItMjUtYmx1ZXNoZWV0DQoNCkFnZW5kYTogaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE2LzAyLzI1L2wzc20vYWdlbmRhL2Fn
ZW5kYS1pbnRlcmltLTIwMTYtbDNzbS0xDQoxLkludHJvZHVjdGlvbg0KQWRtaW5pc3RyaXZpYSBh
bmQgQWdlbmRhIEJhc2ggP0MgKENoYWlycywybWluKQ0KV0cgU3RhdHVzIChjaGFpcnMsIDMgbWlu
KQ0KMi5Xb3JrIGluIFByb2dyZXNzDQpZQU5HIERhdGEgTW9kZWwgZm9yIEwzVlBOIHNlcnZpY2Ug
ZGVsaXZlcnkgP0MgQXV0aG9ycyANCmRyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1vZGVs
DQpPcGVuIElzc3VlcyBEaXNjdXNzaW9uDQpodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9s
M3NtL3RyYWMvcmVwb3J0LzENCjMuQU9CDQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoxLiBJbnRy
b2R1Y3Rpb24NCkNoYWlycw0KU2xpZGVzOiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n
cy9pbnRlcmltLzIwMTYvMDIvMjUvbDNzbS9zbGlkZXMvc2xpZGVzLWludGVyaW0tMjAxNi1sM3Nt
LTEtMS5wZGYNCg0KUWluOiBBaW0gdG8gcmVzb2x2ZSBhbGwgcmVtYWluaW5nIG9wZW4gaXNzdWVz
LCBhbmQgZ2V0IHJlYWR5IGZvciBXRyBsYXN0IGNhbGwNCg0KDQoyLiBMM1NNIGRhdGEgbW9kZWwN
ClN0ZXBoYW5lDQpTbGlkZXM6IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVy
aW0vMjAxNi8wMi8yNS9sM3NtL3NsaWRlcy9zbGlkZXMtaW50ZXJpbS0yMDE2LWwzc20tMS0wLnBk
Zg0KDQpJc3N1ZSAjMyA6IE0gdG8gTiBhdmFpbGFiaWxpdHkNCk5vIGZ1cnRoZXIgY29tbWVudHMg
b24gdGhpcyBmcm9tIHRoZSBtZWV0aW5nLg0KV2Ugd2lsbCBydW4gd2l0aCB3aGF0IHdlIGhhdmUu
DQoNCklzc3VlICM1IDogTXVsdGljYXN0DQpXYWl0aW5nIGZvciBhIHJlc3BvbnNlIGZyb20gRXJp
Yy4NCkJlbm9pdDogeWFuZy1tdWx0aWNhc3RAaWV0Zi5vcmcgaXMgYW4gYWRkcmVzcyBmb3IgYSBZ
QU5HIG1jYXN0IGRlc2lnbiB0ZWFtDQpTdGVwaGFuZSB3aWxsIGNoYXNlDQoNCklzc3VlICM2IDog
SW52ZW50b3J5IG9wcyBzdGF0ZQ0KTm90aGluZyBvbiBsaXN0LiBEbyB3ZSByZWFsbHkgbmVlZCBp
dD8gDQpMdWlzIDogSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGRvIHRoaXMgaW4gdGhpcyBtb2Rl
bC4gTWF5YmUgYWRkIGl0IGxhdGVyLg0KQWRyaWFuIDogQWdyZWUgdGhhdCB0aGlzIGNhbiBiZSBh
ZGRlZCBsYXRlciBhbmQgdGhlcmUgaXNuJ3QgYSBsb3Qgb2YgaW50ZXJlc3QNCkJlbm9pdDogVGhl
IG1vZGVsIGlzIG1haW5seSBhYm91dCB0aGUgY29udmVyc2F0aW9uIGJldHdlZW4gb3BlcmF0b3Ig
YW5kIGN1c3RvbWVyLg0KQWRyaWFuIDogQ2xhcmlmeSB0aGF0IHRoZSBjdXN0b21lciBtYXkgd2Fu
dCB0byBrbm93IHRoZSBzdGF0ZSBvZiB0aGUgc2VydmljZS4gQnV0IHN0aWxsIHRoaW5rIHdlIHNo
b3VsZCBsZWF2ZSBpdCBvdXQgZm9yIG5vdy4NCkFuaCA6IFNlZSB3aGV0aGVyIHRoZXJlIGlzIG1v
cmUgaW50ZXJlc3QuDQpBZHJpYW4gOiBXZSBoYXZlIHRvIGRyYXcgYSBsaW5lIHRvIG1lYXN1cmUg
bm8gbW9yZSBpbnRlcmVzdCwgYW5kIHRoYXQgaXMgbm93Lg0KDQpJc3N1ZSAjOSA6IFRyYW5zcG9y
dCBjb25zdHJhaW50cw0KTm8gbW9yZSBjb21tZW50cy4gSXNzdWUgY2xvc2VkLg0KDQpJc3N1ZSAj
MTAgOiBWUE4gbWVyZ2luZw0KTm90IHJlYWxseSBhIGdvb2QgbmFtZSEgU2VlIHNsaWRlcyBmb3Ig
cmVhbCBpc3N1ZXMuDQpTdWItaXNzdWUgIzEwYSA6IHN1Yi1WUE4gc2NlbmFyaW8NCk11bHRpLVZQ
TiBzY2VuYXJpbyBpcyBhbHJlYWR5IGFkZHJlc3NlZC4gQ0UgbWFpbnRhaW5zIHNlcGFyYXRpb24g
ZW5kLXRvLWVuZCwgYW5kIHRoZXJlIGlzIG9uZSBsb2dpY2FsIGFjY2Vzc3BlciBWUE4uDQoNCkx1
Y3kgOiBQRSBtYWludGFpbnMgaXNvbGF0aW9uIGFzIHdlbGw/DQpTdGVwaGFuZSA6IFllcywgZm9y
IHN1cmUuIEFuZCB0aGF0IGNvbWVzIGF1dG9tYXRpY2FsbHkgaWYgdGhlIENFIGRvZXMgaXQuDQoN
ClN1Yi1pc3N1ZSAjMTBiIDogRXh0cmFuZXQNCkZvdXIgcHJvcG9zYWxzIG9uIHRoZSB0YWJsZQ0K
IzEwYjENCktlbmljaGkgOiBNeSBwcm9wb3NhbCBkb2Vzbid0IG1ha2Ugc2Vuc2Ugd2hlbiB1c2lu
ZyBSRVNUQ09ORiBzbyBJIHdpdGhkcmF3IGl0DQojMTBiMg0KTWljYWhlbCBoYWQgcmFpc2VkIHNv
bWUgaXNzdWVzLg0KQWlqdW4gOiBQcmVmZXIgcHJvcG9zYWwgMyBvdmVyIHByb3Bvc2FsIDIgYmVj
YXVzZSBpdCBkb2Vzbid0IGR1cGxpY2F0ZSB0aGUgc3ViLXRyZWUNClN0ZXBoYW5lIDogWW91IHdv
dWxkIGhhdmUgdG8gZHVwbGljYXRlIG90aGVyIGluZm8uIEZvciBleGFtcGxlIGlmIGEgc2l0ZSBp
cyBpbiB0d28gZGlmZmVyZW50IFZQTnMNCkFpanVuIDogSSB0aGluayB5b3Ugc2hvdWxkIHB1dCB0
aGUgc2l0ZSBpbiB0aGUgU1ZDIGxpc3QuIEFuZCBpZiBzaXRlIGlzIGluIG11bHRpcGxlIFZQTnMg
dGhlbiBpdCB3aWxsIHRvIGJlIGR1cGxpY2F0ZWQuIE90aGVyd2lzZSBuZWVkIHRvIHB1dCBTVkMt
SUQgaW50byBlYWNoIGF0dHJpYnV0ZXMuDQpTdGVwaGFuZSA6IENsYXJpZnkgdGhhdCBwcm9wb3Nh
bCA0IGlzIG5vdCBmb3IgVlBOIHNjZW5hcmlvLiBUaGF0IGlzIGFscmVhZHkgYWRkcmVzc2VkLiBF
eHRyYW5ldCBpcyBhIHN1Yi1jYXNlIG9mIG11bHRpLVZQTiB3aGVyZSB3ZSBjYW4gbWFrZSBhIHNo
b3J0Y3V0IHNheWluZyAiZm9yIHRoaXMgVlBOIGFsbCBvZiB0aGUgc2l0ZXMgd2lsbCBjb25uZWN0
IHRvIGFub3RoZXIgVlBOIiANCkx1aXM6IElzIHRoaXMgYSBjb2Rpbmcgc2ltcGxpY2l0eSBpc3N1
ZT8NClN0ZXBoYW5lOiBKdXN0IGEgc2ltcGxpZmNhdGlvbiBpbiB0aGUgZGF0YSBtb2RlbC4gS2Vu
aWNoaSdzIHVzZSBjYXNlIGNvdWxkIGJlIGFjaGlldmVkIHVzaW5nIFZQTiBwb2xpY3ksIGJ1dCBp
dCBpcyBoZWF2eS4gU28gdGhpcyBpcyBhbiBkZGl0aW9uYWwgb3B0aW9uIHRvIHByb3ZpZGUgYSBz
aG9ydGN1dC4NCkx1aXM6IFRoZSBtb2RlbCBjYW4gc29sdmUgaXQgYWxyZWFkeSwgc28gdGhpcyBp
cyBhbiBlZmZpY2llbmN5IHRoaW5nDQpTdGVwaGFuZTogSXQgbWF5IGRlcGVuZCBvbiBob3cgdGhl
IGN1c3RvbWVyIGFjY2Vzc2VzIHRoZSBtb2RlbC4gVmlhIGEgcG9ydGFsIGl0IGRvZXNuJ3QgbWF0
dGVyLiBWaWEgYW4gQVBJIHRoZSBzaW1wbGlmaWNhdGlvbiB3aWxsIGhlbHAuDQpBZHJpYW46IERv
ZXMgYW55b25lIG9uIHRoZSBjYWxsIGhhdmUgYW4gaXNzdWUgb3IgY29uY2VybiB3aXRoIGdvaW5n
IHdpdGggcHJvcG9zYWwgIzQ/DQpTSUxFTkNFDQpBZHJpYW46IFN0ZXBoYW5lIHBsZWFzZSB1cGRh
dGUgdGhlIGRvY3VtZW50IHRoaXMgd2F5LCBhbmQgd2UnbGwgY2F0Y2ggYW55IGZ1cnRoZXIgY29u
Y2VybnMgaW4gcmV2aWV3IG9yIGxhc3QgY2FsbA0KDQpCYWNrIHRvIFN1Yi1pc3N1ZSAjMTBhIDog
U3ViLVZQTg0KVGhyZWUgcHJvcG9zYWxzIGhhdmUgYmVlbiBtYWRlDQpHbyBmb3IgcHJvcG9zYWwg
IzIgaWYgd2UgYXJlIGFibGUgdG8gaW1wbGVtZW50Lg0KQW5oOiBCZXN0IHByYWN0aWNlIGlzIHRv
IGNyZWF0ZSBzZWNvbmQgZWxlbWVudCBmb3Igc2hhcmVkIHJlc291cmNlDQpLZW5pY2hpOiBBcmUg
eW91IHNheWluZyB3ZSBuZWQgYSBDRSBvciBQRSBzZXJ2aWNlIG1vZGVsPw0KU3RlcGhhbmU6IEZy
b20gYSBzZXJ2aWNlIG1vZGVsIFBvViB3ZSBhcmUgbm90IGF3YXJlIG9mIENFIG9yIFBFLiBKdXN0
IGF0dGFjaG1lbnQNCkFuaDogV2hhdCB5b3UgdGFsayBhYm91dCBhdGFjaG1lbnQgaXMgdGhlIGFz
c2lnbm1lbnQgb2YgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIENFIGFuZCBWUE4uIEkgcHJvcG9z
ZSBhbiBhc3NpZ25tZW50IHJlY29yZA0KS2VuaWNoaTogRW1haWwgb2YgSmFuIDE5dGguIFBoeXNp
Y2FsbHkgQ0UgZXhpc3RzLCBidXQgd2UgZG9uJ3Qga25vdyBob3cgbWFueSBDRXMgdGhlIGN1c3Rv
bWVyIGlzIHVzaW5nLiBNYXliZSBtdWx0aXBsZSBWUkZzIG9yIHBoeXNpY2FsbHkgc2VwYXJhdGUg
Q0VzLiBTZXJ2aWNlIG1vZGVsIGRvZXMgbm90IChzaG91bGQgbm90PykgZGVmaW5lIHN1Y2ggc2Nl
bmFyaW9zLiBOZWVkIHRvIHNpbXBsaWZ5IGFuZCBrZWVwIHRoaXMgb3V0IG9mIHNjb3BlIGluIHNl
cnZpY2UgbW9kZWwuDQpBbmg6IFBvcHVsYXIgZm9yIGN1c3RvbWVycyB0byBnaXZlIGlkZW50aXR5
IG9mIENFDQpBbmg6IE91ciBwcm9wb3NhbHMgYXJlIHRoZSBzYW1lLiBKdXN0IHRlcm1pbm9sb2d5
LiBZb3Ugc3kgInN1Yi1zaXRlIiBJIHNheSAiYXNzb2NpYXRpb24gcmVsYXRpb25zaGlwIg0KU3Rl
cGhhbmUgZG9lcyBhIGRyYXdpbmcgaW4gcmVhbC10aW1lIFtXaWxsIHRyeSB0byBnZXQgaXQgdXBs
b2FkZWQgaW4gdGhlIHNsaWRlIHNldF0NCg0KQWRyaWFuOiBEaXNjdXNzaW9uIG5vdCBmdWxseSBy
ZXNvbHZlZC4gVGFibGVkIGZvciBkZWJhdGUgb24gbGlzdC4gQXNraW5nIEx1Y3kgdG8gd3JpdGUg
dXAgaGVyIGNvbmNlcm4gZm9yIGRpc2N1c3Npb24uDQoNCklzc3VlICMxMiA6IA0KTm8gY29tbWVu
dHMgcmFpc2VkDQoNCklzc3VlICMxNCA6IE5vdGlmaWNhdGlvbnMNCkNsb3NlZCB1bmRlciB0aGUg
ZGlzY3Vzc2lvbiBvZiBvcGVyYXRpb25hbCBzdGF0ZQ0KTm8gZnVydGhlciBhY3Rpb24NCg0KLSAt
IC0gLQ0KDQpTaG91bGQgdGhlIHNpdGUgYmUgcHV0IHVuZGVyIFZQTi1TVkM/DQpBaWp1biBleHBs
YWlucyBoaXMgcHJvcG9zYWwgYnkgbG9va2luZyBhdCBoaXMgZW1haWwgdG8gdGhlIGxpc3QgZnJv
bSAyNS8yLzE2IHRpdGxlZCAiIFJlOltMM3NtXSBJc3N1ZSAjMTAgUkU6IEwzU00gaW50ZXJpbSBt
ZWV0aW5nIG1pbnV0ZXMgb24gVGh1cnNkYXkgTDNTTSBpbnRlcmltc2Vzc2lvbiENClN0ZXBoYW5l
OiBJZiB5b3UgZG8gdGhpcywgZXZlcnkgdGltZSB5b3UgYXR0YWNoIGEgc2l0ZSB0byBhIG5ldyBW
UE4geW91IHdpbGwgaGF2ZSB0byBjb21wbGV0ZWx5IHJlLWVudGVyIGFsbCBvZiB0aGUgaW5mb3Jt
YXRpb24uIFdoYXQgYXJlIHlvdSBpbXByb3ZpbmcgY29tcGFyZWQgdG8gd2hhdCB3ZSB0YWxrZWQg
YWJvdXQgZWFybGllcj8gT24gdGhlIG90aGVyIGhhbmQsIEkgc2VlIHNvbWUgbW9yZSBpc3N1ZXMu
DQpBaWp1bjogSSdsbCB0YWtlIHRoaXMgdG8gZW1haWwNClN0ZXBoYW5lOiBEb2VzIHNvbWVvbmUg
c2VlIGEgYmVuZWZpdCB0byBwdXR0aW5nIHRoZSBhdHRyaWJ1dGVzIG9mIHRoZSBzaXRlIHVuZGVy
IHRoZSBWUE4gU1ZDDQpBaWp1bjogTWF4aW11bSBsb2FkIGFuZCBzZWN1cml0eSBtYXkgdmFyeSBm
b3IgYSBzaXRlIGRlcGVuZGluZyBvbiB3aGljaCBWUE4gaXQgaXMgaW4uIEFsc28gYXR0YWNobWVu
dCBtYXkgYmUgZGlmZmVyZW50Lg0KU3RlcGhhbmU6IEhvdyBjYW4gYXR0YWNobWVudCBiZSBkaWZm
ZXJlbnQ/IEl0IGlzIGVzc2VudGlhbCB0byBhIHNpdGUNCkFpanVuOiBSb3V0aW5nIHByb3RvY29s
IGlzIGEgZmVhdHVyZSBvZiBhdHRhY2htZW50IGFuZCBtYXkgYmUgZGlmZmVyZW50IHBlciBWUE4N
ClN0ZXBoYW5lOiBEaXNnYXJlZQ0KQWlqdW46IEhvdyB3b3VsZCB5b3UgaGFuZGxlIGEgc2l0ZSB0
aGF0IHVzZXMgb25lIHByb3RvY29sIGluIG9uZSBWUE4gYW5kIGEgZGlmZmVyZW50IHByb3RvY29s
IGluIGEgZGlmZmVyZW50IFZQTj8NClM6IEFyZSB5b3UgdGFsa2luZyBhYm91dCBtdWx0aS1WUE4g
b3Igc3ViLVZQTiBzY2VuYXJpbz8gKEV4cGxhaW5zIGhvdyBib3RoIHdvcmspDQpBOiBDb25zaWRl
ciBzdWItVlBOIHNjZW5hcmlvIHdpdGggc2V2ZXJhbCBsb2dpY2FsIGFjY2Vzc2VzIGZvciBkaWZm
ZXJlbnQgVlBOcy4NClM6IFNpdGUgaGFzIG11bHRpcGxlICJzaXRlIG5ldHdvcmsgYWNjZXNzIiBj
b250YWluZXJzIA0KDQpBZHJpYW46IFdlIHNlZW0gdG8gaGF2ZSBubyBjb25zZW5zdXMgc28gd2Ug
bmVlZHRvIGdvdG8gdGhlIGxpc3QuDQoNCiMxMyBUbyBkbyBsaXN0DQoxLiBTZWN1cml0eTogTmVl
ZHMgYXR0ZW50aW9uDQpJdGVtcyAyLTQNCkFkcmlhbjogSWYgbm8tb25lIHNwZWFrcyB1cCB0aGVz
ZSB3aWxsIGJlY29tZSBub24taXNzdWVzDQpMdWlzOiBUaGVzZSBsb29rIGxpa2Ugc3N1ZXMgb2Yg
cHVibGljIFZQTiBvciBoeWJyaWQgVlBODQpMdWN5OiBXaGF0IGRvZXMgaXRlbSAyIG1lYW4/IElz
IHRoaXMgYSBzZXJ2aWNlPw0KTHVpczogQ0UtYmFzZWQgVlBOcyBhcmUgbm90IG9idmlvdXNseSBp
biBzY29wZQ0KTHVjeTogSXRlbSAzIFdoYXQgb3RoZXIgc2NlbmFyaW9zIGFyZSB0aGVyZT8NCkFk
cmlhbjogU3RlcGhhbmUgc2VlbXMgdG8gYmUgc2F5aW5nIHRoYXQgbm90aGluZyBuZWVkcyB0byBi
ZSBhZGRlZCBpbiB0aGUgc2VydmljZSBtb2RlbA0KTHVpczogRm9yIG9wdGlvbiBBIHRoaXMgc2hv
dWxkIHdvcmsNCkx1Y3k6IEV2ZW4gZm9yIG9wdGlvbiBBIHRoZXJlIHdpbGwgYmUgZGV0YWlscyB0
aGF0IGFyZSBuZWVkZWQgZm9yIHRoZSBzZXJ2aWNlIHRvIGJlIGRlbGl2ZXJlZC4gU3VwcG9zZSBh
IFZQTiBzcGFucyBtdWx0aXBsZSBwcm92aWRlcnM6IGhvdyBkb2VzIG9uZSBzZXJ2aWNlIHByb3Zp
ZGVyIGtub3cgd2hlcmUgdGhlIG90aGVyIHNpdGVzIGFyZSBsb2NhdGVkPw0KTHVpczogUmlnaHQg
bm93LCB3ZSBhc2sgZm9yIHRoZSBjdXN0b21lcidzIEFTLiBJcyB5b3VyIHBvaW50IHRoYXQgd2Ug
bmVlZCB0byB0ZWxsIHRoZSBjdXN0b21lciB3aGF0IEFTIHRoZXkgYXJlIGF0dGFjaGVkIHRvPw0K
DQpJdGVtIDQ6DQogICAgTHVpcywgbWFrZXMgbm8gc2Vuc2UgaWZ3ZSBsaW1pdCB0byB0aGUgUEUt
YmFzZWQgbW9kZWwNCg0KQW5oOiBEbyB3ZSBzdXBwb3J0IHBhcnRpYWwgbWVzaD8gSWYgbm8gaW50
ZXJlc3QgdGhlbiBsZXQncyBrZWVwIGl0IHNpbXBsZQ0KDQotIC0gLSAtIC0NCg0KQWRyaWFuOiBU
aGUgcGxhbiBpcyB0aGF0IFN0ZXBoYW5lIHdpbGwgdXBkYXRlIHRoZSBJLUQNCk5vdCBzdXJlIHdo
ZXRoZXIgd2Ugd2lsbCBtZWV0IGluIEJ1ZW5vcyBBaXJlcy4gV2UgaGF2ZSBhIHNsb3QgYm9va2Vk
YnV0IHRoZXJlIG5vdCBiZSBtdWNoIHRvIHRhbGsgYWJvdXQgYW5kIHNldmVyYWwga2V5IHBlb3Bs
ZSBhcmUgdW5saWtlbHkgdG8gdHJhdmVsLg0KQSBjb3VwbGUgb2YgeW91IGhhdmUgdGFrZW5hY3Rp
b25zIHRvIHJhaXNlIGlzc3VlcyBvbiB0aGUgbGlzdC4gUGxlYXNlIGRvIHNvLg0KVGhhbmtzdG9h
bGwgYW5kIGdvb2RieWUuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg==

--_004_B8F9A780D330094D99AF023C5877DABA852C2C15nkgeml513mbxchi_--


From nobody Thu Feb 25 19:15:47 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB76F1A886F for ; Thu, 25 Feb 2016 19:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.156
X-Spam-Level: 
X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 OekN67MM3PHK for ; Thu, 25 Feb 2016 19:15:43 -0800 (PST)
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 A18DA1A8889 for ; Thu, 25 Feb 2016 19:15:42 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJE42550; Fri, 26 Feb 2016 03:15:40 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Feb 2016 03:15:39 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Fri, 26 Feb 2016 11:15:29 +0800
From: Qin Wu 
To: Lucy yong , "l3sm@ietf.org" 
Thread-Topic: L3 service model suggestion
Thread-Index: AdFv5NXohY58UF8wRLqEAwIfFWnLNAAXBAtA
Date: Fri, 26 Feb 2016 03:15:29 +0000
Message-ID: 
References: <2691CE0099834E4A9C5044EEC662BB9D57245D3B@dfweml701-chm>
In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D57245D3B@dfweml701-chm>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.78.208]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA852C2C7Dnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56CFC35C.00BD, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6955d8bc56b3bface32c4f3b618da465
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2016 03:15:46 -0000

--_000_B8F9A780D330094D99AF023C5877DABA852C2C7Dnkgeml513mbxchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGksIEx1Y3k6DQq3orz+yMs6IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddILT6
se0gTHVjeSB5b25nDQq3osvNyrG85DogMjAxNsTqMtTCMjXI1SAyMzo1OQ0KytW8/sjLOiBsM3Nt
QGlldGYub3JnDQrW98ziOiBbTDNzbV0gTDMgc2VydmljZSBtb2RlbCBzdWdnZXN0aW9uDQoNCkhp
IEFsbCwNCg0KQ3VycmVudCBMM3ZwbiBzZXJ2aWNlIG1vZGVsICh0aGUgZHJhZnQpIHNwZWNpZmll
cyB2cG4tc3ZjIGFuZCBzaXRlIGNvbnRhaW5lcnMgb25seS4gSW4gb3JkZXIgdG8gYWRkcmVzcyBt
dWx0aXBsZSB2cG4gYXQgb25lIHNpdGUsIHdlIG5lZWQgdnBuLXN2YyBwZXIgc2l0ZSBjb250YWlu
ZXIgdG9vLiBTb21lIGF0dHJpYnV0ZXMgdW5kZXIgc2l0ZSBjb250YWluZXIgc2hvdWxkIGJlbG9u
ZyB0byB2cG4tc3ZjIHBlciBzaXRlIGNvbnRhaW5lciBzdWNoIGFzIHZwbi1wb2xpY3ksIHNlcnZp
Y2UsIGV0Yy4NCg0KW1Fpbl06IEkgYmVsaWV2ZSB2cG4tcG9saWN5IGhhcyBhbHJlYWR5IGJlZW4g
bW9kZWxlZCBhcyB2cG4tc3ZjIHBlciBzaXRlLCBzZWUgc2VjdGlvbiA1LjIuMg0KaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1vZGVsLTAy
I3NlY3Rpb24tNS4yLjINCkZvciBzZXJ2aWNlLCB3aGF0IGFyZSBkZWZpbmVkIGZvciBzZXJ2aWNl
IGFyZSBjb21tb24gYXR0cmlidXRlcyB0aGF0IGFyZSBhcHBsaWVkIHRvIGFsbCB0aGUgVlBOIHNl
cnZpY2UgaWYgb25lIHNpdGUgYmVsb25naW5nIHRvIG11bHRpcGxlIFZQTiBzZXJ2aWNlLg0KUGxl
YXNlIHNlZSBleGFtcGxlcyBpbiB0aGUgc2VjdGlvbiA1LjIuNi4NCg0KVGhlIHNpdGUgY29udGFp
bmVyIG5lZWRzIHRvIGhhdmUgYSBwYXJhbWV0ZXIgobBtdWx0aXBsZXhpbmehsSB0byBpbmRpY2F0
ZSBpZiBhIHNpdGUgd2lsbCBoYXZlIHNpbmdsZSB2cG4gb3IgbXVsdGlwbGUgdnBuLiBUaGlzIHdp
bGwgYWRkcmVzcyB0aGUgaXNzdWUgb2YgbXVsdGktdnBuIGF0IGEgc2l0ZSBkaXNjdXNzZWQgaW4g
dG9kYXmhr3MgaW50ZXJpbSBtZWV0aW5nLg0KDQpbUWluXTogRm9yIHZwbi1wb2xpY3ksIGl0IGlz
IGltcGxpY2l0bHkgaW5kaWNhdGVkIGJ5IHRoZSBudW1iZXIgb2YgcG9saWN5IGVudHJpZXMuDQoN
Ck5vdCBzdXJlIHdoeSBuZWVkIHNpdGUtdGVtcGxhdGUgY29udGFpbmVyLg0KDQpbUWluXTogU2l0
ZS10ZW1wbGF0ZXMgYWxsb3cgdG8gZGVmaW5lIGNvbmZpZ3VyYXRpb24gYmxvY2tzIHRoYXQgd2ls
bCBiZSAgaW5oZXJpdGVkIGJ5IG9uZSBvciBtdWx0aXBsZSBzaXRlcyBpbiBvcmRlciB0byBzcGVl
ZCB1cA0KICAgY29uZmlndXJhdGlvbi4gU2VlIG1vcmUgZGV0YWlscyBpbiBzZWN0aW9uIDUuNCBv
ZiBzZXJ2aWNlIG1vZGVsIGRyYWZ0Lg0KDQpSZWdhcmRzLA0KTHVjeQ0K

--_000_B8F9A780D330094D99AF023C5877DABA852C2C7Dnkgeml513mbxchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi, Lucy:






=B7=A2=BC=FE=C8=CB: L3sm [m=
ailto:l3sm-bounces@ietf.org]
=B4=FA=
=B1=ED Lucy yong

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C225=C8=D5
 23:59

=CA=D5=BC=FE=C8=CB: l3sm@ietf.org

=D6=F7=CC=E2: [L3sm] L3 service model suggestion






 


Hi All,


 


Current L3vpn service model (th=
e draft) specifies vpn-svc and site containers only. In order to address mu=
ltiple vpn at one site, we need vpn-svc per site container too. Some attrib=
utes under site container should belong
 to vpn-svc per site container such as vpn-policy, service, etc. 



 


[Qin]: I believe vpn-policy has already been modeled as vpn-svc p=
er site, see section 5.2.2


https://tools.ietf.org/html/draft-ietf-l3sm-l3vpn-service-model-0=
2#section-5.2.2


For service, what are defined for service are common attributes t=
hat are applied to all the VPN service if one site belonging to multiple VP=
N service.


Please see examples in the section 5.2.6.


 


The site container needs to hav=
e a parameter =A1=B0multiplexing=A1=B1 to indicate if a site will have sing=
le vpn or multiple vpn. This will address the issue of multi-vpn at a site =
discussed in today=A1=AFs interim meeting.


&n=
bsp;


[Qin]: For vpn-policy, it is implicitly indicated by the number o=
f policy entries.


 


Not sure why need site-template=
 container.


&n=
bsp;


[Qin]: Site-templates allow to define configuration blocks that w=
ill be  inherited by one or multiple sites in order to speed up


   configuration. See more details in section 5.4 of se=
rvice model draft.


 


Regards,


Lucy






--_000_B8F9A780D330094D99AF023C5877DABA852C2C7Dnkgeml513mbxchi_--


From nobody Thu Feb 25 19:28:42 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6211A88DE for ; Thu, 25 Feb 2016 19:28:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.156
X-Spam-Level: 
X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 uEZVICzYsQ6c for ; Thu, 25 Feb 2016 19:28:39 -0800 (PST)
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 E44241A88E6 for ; Thu, 25 Feb 2016 19:28:38 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFA05022; Fri, 26 Feb 2016 03:28:34 +0000 (GMT)
Received: from LHREML707-CAH.china.huawei.com (10.201.5.199) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Feb 2016 03:27:34 +0000
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Feb 2016 03:27:33 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 26 Feb 2016 11:27:22 +0800
From: Qin Wu 
To: Aijun Wang <13301168517@189.cn>, Lucy yong , "l3sm@ietf.org" 
Thread-Topic: [L3sm]  L3 service model suggestion
Thread-Index: AQHRcDQuAYGXhyy/kkC3FcGET9yjfp89qbQA
Date: Fri, 26 Feb 2016 03:27:21 +0000
Message-ID: 
References: <005001d17034$26bb1460$74313d20$@cn>
In-Reply-To: <005001d17034$26bb1460$74313d20$@cn>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.78.208]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA852C2C96nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56CFC662.0149, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: fc4311c247dc5dbfc872fe378221c789
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2016 03:28:42 -0000

--_000_B8F9A780D330094D99AF023C5877DABA852C2C96nkgeml513mbxchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

QWlqdW46DQpJIGJlbGlldmUgd2hhdCB5b3Ugd2FudCBpcyBzaXRlIGF0dHJpYnV0ZSBwZXIgdnBu
LXN2YyB3aGlsZSBMdWN5IGlzIHRhbGtpbmcgYWJvdXQgdnBuLXN2YyBwZXIgc2l0ZQ0KVGhleSBh
cmUgdHdvIGRpZmZlcmVudCB0aGluZ3MuDQoNCi1RaW4NCreivP7IyzogTDNzbSBbbWFpbHRvOmwz
c20tYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBBaWp1biBXYW5nDQq3osvNyrG85DogMjAxNsTqMtTC
MjbI1SA5OjIyDQrK1bz+yMs6IEx1Y3kgeW9uZzsgbDNzbUBpZXRmLm9yZw0K1vfM4jogW0wzc21d
IEwzIHNlcnZpY2UgbW9kZWwgc3VnZ2VzdGlvbg0KDQpIaSwgTHVjeToNCg0KSXMgaXQgbW9yZSBj
bGVhciB0byBwdXQgdGhlIGxpc3Qgc2l0ZSB3aXRoaW4gdGhlIGxpc3QgdnBuLXN2Yz8gVGhpcyBj
b3JyZWxhdGUgbmF0dXJhbGx5IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB2cG4gaWQgYW5kIGl0
cyBhc3NvY2lhdGVkIHNpdGVzLCBhbmQgYWxzbyB0aGUgYXR0cmlidXRlcyBvZiB0aGVzZSBzaXRl
cy4NCkZvciBzaXRlIHRoYXQgYmVsb25nIHRvIG11bHRpcGxlIHZwbiwgdGhlIHNpdGWhryBpbmZv
cm1hdGlvbiB3aWxsIGJlIGV4aXN0ZWQgaW4gc2V2ZXJhbCBzcGVjaWZpYyB2cG4gY29udGV4dC4g
Q29uc2lkZXJpbmcgdGhlIHNpdGWhr3MgYXR0cmlidXRlIG1heSBiZSB2YXJ5IGZvciBkaWZmZXJl
bnQgdnBuLCBpdCBpcyByZWFzb25hYmxlIGZvciB0aGUgY3VzdG9tZXIuDQoNCkZvciBzaXRlLXRl
bXBsYXRlIGNvbnRhaW5lciwgSSBwcm9wb3NlOg0KMS4gIHdlIGNoYW5nZSBpdCBpbnRvIGdyb3Vw
aW5nIHNpdGUtdGVtcGxhdGUsIGFuZCB1c2UgaXQgd2l0aGluIGxpc3Qgc2l0ZXMsIG9yDQoyLiBk
ZWZpbmUgdGhlIHJlbGF0ZWQgaXRlbXMgZGlyZWN0bHkgIHdpdGhpbiB0aGUgbGlzdCBzaXRlcyBh
bmQgZWxpbWluYXRlIHRoZSBzaXRlLXRlbXBsYXRlIGNvbnRhaW5lci4NCg0KQmVzdCBSZWdhcmRz
Lg0KDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgTHVjeSB5b25nDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjUsIDIwMTYgMTE6NTkgUE0N
ClRvOiBsM3NtQGlldGYub3JnPG1haWx0bzpsM3NtQGlldGYub3JnPg0KU3ViamVjdDogW0wzc21d
IEwzIHNlcnZpY2UgbW9kZWwgc3VnZ2VzdGlvbg0KDQpIaSBBbGwsDQoNCkN1cnJlbnQgTDN2cG4g
c2VydmljZSBtb2RlbCAodGhlIGRyYWZ0KSBzcGVjaWZpZXMgdnBuLXN2YyBhbmQgc2l0ZSBjb250
YWluZXJzIG9ubHkuIEluIG9yZGVyIHRvIGFkZHJlc3MgbXVsdGlwbGUgdnBuIGF0IG9uZSBzaXRl
LCB3ZSBuZWVkIHZwbi1zdmMgcGVyIHNpdGUgY29udGFpbmVyIHRvby4gU29tZSBhdHRyaWJ1dGVz
IHVuZGVyIHNpdGUgY29udGFpbmVyIHNob3VsZCBiZWxvbmcgdG8gdnBuLXN2YyBwZXIgc2l0ZSBj
b250YWluZXIgc3VjaCBhcyB2cG4tcG9saWN5LCBzZXJ2aWNlLCBldGMuIFRoZSBzaXRlIGNvbnRh
aW5lciBuZWVkcyB0byBoYXZlIGEgcGFyYW1ldGVyIKGwbXVsdGlwbGV4aW5nobEgdG8gaW5kaWNh
dGUgaWYgYSBzaXRlIHdpbGwgaGF2ZSBzaW5nbGUgdnBuIG9yIG11bHRpcGxlIHZwbi4gVGhpcyB3
aWxsIGFkZHJlc3MgdGhlIGlzc3VlIG9mIG11bHRpLXZwbiBhdCBhIHNpdGUgZGlzY3Vzc2VkIGlu
IHRvZGF5oa9zIGludGVyaW0gbWVldGluZy4NCg0KTm90IHN1cmUgd2h5IG5lZWQgc2l0ZS10ZW1w
bGF0ZSBjb250YWluZXIuDQoNClJlZ2FyZHMsDQpMdWN5DQo=

--_000_B8F9A780D330094D99AF023C5877DABA852C2C96nkgeml513mbxchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Aijun:


I believe what you want is site attribute per vpn-svc while Lucy =
is talking about vpn-svc per site


They are two different things.


 


-Qin






=B7=A2=BC=FE=C8=CB: L3sm [m=
ailto:l3sm-bounces@ietf.org]
=B4=FA=
=B1=ED Aijun Wang

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C226=C8=D5
 9:22

=CA=D5=BC=FE=C8=CB: Lucy yong; l3sm@ietf.org

=D6=F7=CC=E2: [L3sm] L3 service model suggestion






 


Hi, Lucy:


 


Is it more clear to put the list site within the list vpn-svc? Th=
is correlate naturally the relationship between vpn id and its associated s=
ites, and also the attributes of these
 sites.


For site that belong to multiple vpn, the site=A1=AF information =
will be existed in several specific vpn context. Considering the site=A1=AF=
s attribute may be vary for different vpn, it is
 reasonable for the customer.


 


For site-template container, I propose:


1.  we change it into grouping site-template, and use it wit=
hin list sites, or


2. define the related items directly  within the list sites =
and eliminate the site-template container.


 


Best Regards.


 






From: L3sm [mailto=
:l3sm-bounces@ietf.org]
On Behalf Of Lucy yong

Sent: Thursday, February 25, 2016 11:59 PM

To: l3sm@ietf.org

Subject: [L3sm] L3 service model suggestion






 


Hi All,


 


Current L3vpn service model (th=
e draft) specifies vpn-svc and site containers only. In order to address mu=
ltiple vpn at one site, we need vpn-svc per site container too. Some attrib=
utes under site container should belong
 to vpn-svc per site container such as vpn-policy, service, etc. The site c=
ontainer needs to have a parameter =A1=B0multiplexing=A1=B1 to indicate if =
a site will have single vpn or multiple vpn. This will address the issue of=
 multi-vpn at a site discussed in today=A1=AFs
 interim meeting.


 


Not sure why need site-template=
 container.


 


Regards,


Lucy






--_000_B8F9A780D330094D99AF023C5877DABA852C2C96nkgeml513mbxchi_--


From nobody Fri Feb 26 00:28:30 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B10D1ACD56 for ; Fri, 26 Feb 2016 00:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.304
X-Spam-Level: 
X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 seJwUWUPdsbf for ; Fri, 26 Feb 2016 00:28:24 -0800 (PST)
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 CB36A1ACD72 for ; Fri, 26 Feb 2016 00:28:23 -0800 (PST)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 33A03C019F; Fri, 26 Feb 2016 09:28:22 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 032311A005E; Fri, 26 Feb 2016 09:28:22 +0100 (CET)
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; Fri, 26 Feb 2016 09:28:21 +0100
From: 
To: Aijun Wang <13301168517@189.cn>, 'Lucy yong' , "l3sm@ietf.org" 
Thread-Topic: [L3sm]  L3 service model suggestion
Thread-Index: AQHRcDQlKf5V3VVA60qHAvxleY5vDJ89/Njw
Date: Fri, 26 Feb 2016 08:28:21 +0000
Message-ID: <28091_1456475302_56D00CA6_28091_2131_1_9E32478DFA9976438E7A22F69B08FF92168CDD59@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <005001d17034$26bb1460$74313d20$@cn>
In-Reply-To: <005001d17034$26bb1460$74313d20$@cn>
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: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92168CDD59OPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2016 08:28:27 -0000

--_000_9E32478DFA9976438E7A22F69B08FF92168CDD59OPEXCLILMA4corp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Again,  in a multiVPN scenario, we have a SINGLE logical site so if you use=
 site under vpn-svc you will have to duplicate all the site information (ro=
uting-protocols, security , ip addressing ...) and it's useless because it =
will be exactly the same. So the model becomes really heavy to use while to=
day it's really flexible.
This duplication is a no GO for me. Now if you go to use a reference to a t=
emplate, it's exactly the same like having a site-list with references only=
 that I proposed, but Michael had a very good argument telling that splitti=
ng the site attributes in two subtree is a very bad idea.

I don't really understand the old argument telling that putting sites under=
 vpn is more service oriented. This is for sure another way to model it, bu=
t the current way is also service oriented but we separate sites and VPN to=
 have the best flexibility in mapping sites to VPNs. Multiple service provi=
ders are using this kind of separation between VPN and sites in their infor=
mation system today (this was one of the first outcomes when we started thi=
s modeling exercice).

Now from an operational point of view (not configuration), people need to e=
asy access the list of sites per VPN, we can create an read-only container =
for that purpose.


From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, February 26, 2016 02:22
To: 'Lucy yong'; l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi, Lucy:

Is it more clear to put the list site within the list vpn-svc? This correla=
te naturally the relationship between vpn id and its associated sites, and =
also the attributes of these sites.
For site that belong to multiple vpn, the site' information will be existed=
 in several specific vpn context. Considering the site's attribute may be v=
ary for different vpn, it is reasonable for the customer.

For site-template container, I propose:
1.  we change it into grouping site-template, and use it within list sites,=
 or
2. define the related items directly  within the list sites and eliminate t=
he site-template container.

Best Regards.

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, February 25, 2016 11:59 PM
To: l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi All,

Current L3vpn service model (the draft) specifies vpn-svc and site containe=
rs only. In order to address multiple vpn at one site, we need vpn-svc per =
site container too. Some attributes under site container should belong to v=
pn-svc per site container such as vpn-policy, service, etc. The site contai=
ner needs to have a parameter "multiplexing" to indicate if a site will hav=
e single vpn or multiple vpn. This will address the issue of multi-vpn at a=
 site discussed in today's interim meeting.

Not sure why need site-template container.

Regards,
Lucy

___________________________________________________________________________=
______________________________________________

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_9E32478DFA9976438E7A22F69B08FF92168CDD59OPEXCLILMA4corp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,<=
/p>

 


Again,  in a mult=
iVPN scenario, we have a SINGLE logical site so if you use site under vpn-s=
vc you will have to duplicate all the site information (routing-protocols, =
security , ip addressing …) and it’s useless
 because it will be exactly the same. So the model becomes really heavy to =
use while today it’s really flexible.


This duplication is a =
no GO for me. Now if you go to use a reference to a template, it’s ex=
actly the same like having a site-list with references only that I proposed=
, but Michael had a very good argument telling
 that splitting the site attributes in two subtree is a very bad idea.=



 


I don’t really u=
nderstand the old argument telling that putting sites under vpn is more ser=
vice oriented. This is for sure another way to model it, but the current wa=
y is also service oriented but we separate
 sites and VPN to have the best flexibility in mapping sites to VPNs. Multi=
ple service providers are using this kind of separation between VPN and sit=
es in their information system today (this was one of the first outcomes wh=
en we started this modeling exercice).


 


Now from an operationa=
l point of view (not configuration), people need to easy access the list of=
 sites per VPN, we can create an read-only container for that purpose.=



 


 






From: L3sm [ma=
ilto:l3sm-bounces@ietf.org]
On Behalf Of Aijun Wang

Sent: Friday, February 26, 2016 02:22

To: 'Lucy yong'; l3sm@ietf.org

Subject: [L3sm] L3 service model suggestion






 


Hi, Lucy:


 


Is it more clear to put the list site within the list=
 vpn-svc? This correlate naturally the relationship between vpn id and its =
associated sites, and also the attributes
 of these sites.


For site that belong to multiple vpn, the site’=
 information will be existed in several specific vpn context. Considering t=
he site’s attribute may be vary for different
 vpn, it is reasonable for the customer.


 


For site-template container, I propose:


1.  we change it into grouping site-template, an=
d use it within list sites, or


2. define the related items directly  within the=
 list sites and eliminate the site-template container.


 


Best Regards.


 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of Lucy yong

Sent: Thursday, February 25, 2016 11:59 PM

To: l3sm@ietf.org

Subject: [L3sm] L3 service model suggestion






&nbs=
p;


Hi All,


&nbs=
p;


Current L=
3vpn service model (the draft) specifies vpn-svc and site containers only. =
In order to address multiple vpn at one site, we need vpn-svc per site cont=
ainer too. Some attributes under site
 container should belong to vpn-svc per site container such as vpn-policy, =
service, etc. The site container needs to have a parameter “multiplex=
ing” to indicate if a site will have single vpn or multiple vpn. This=
 will address the issue of multi-vpn at a site
 discussed in today’s interim meeting.


&nbs=
p;


Not sure =
why need site-template container.


&nbs=
p;


Regards,<=
o:p>


Lucy=





______________________________________________________________________=
___________________________________________________

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


From nobody Fri Feb 26 07:27:41 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEE21A6FA8 for ; Fri, 26 Feb 2016 07:27:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.606
X-Spam-Level: 
X-Spam-Status: No, score=-3.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 9UKYzydBQLVQ for ; Fri, 26 Feb 2016 07:27:35 -0800 (PST)
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 99AAE1A6F93 for ; Fri, 26 Feb 2016 07:27:34 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJF17070; Fri, 26 Feb 2016 15:27:31 +0000 (GMT)
Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Feb 2016 15:27:30 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Fri, 26 Feb 2016 07:27:24 -0800
From: Lucy yong 
To: "stephane.litkowski@orange.com" , "Aijun Wang" <13301168517@189.cn>, "l3sm@ietf.org" 
Thread-Topic: [L3sm]  L3 service model suggestion
Thread-Index: AQHRcDQlKf5V3VVA60qHAvxleY5vDJ89/NjwgABxxpA=
Date: Fri, 26 Feb 2016 15:27:23 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5724619D@dfweml701-chm>
References: <005001d17034$26bb1460$74313d20$@cn> <28091_1456475302_56D00CA6_28091_2131_1_9E32478DFA9976438E7A22F69B08FF92168CDD59@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <28091_1456475302_56D00CA6_28091_2131_1_9E32478DFA9976438E7A22F69B08FF92168CDD59@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.135.10]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D5724619Ddfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56D06EE3.014A, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 25e477c285de2d9f704cfbb45a64624b
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2016 15:27:40 -0000

--_000_2691CE0099834E4A9C5044EEC662BB9D5724619Ddfweml701chm_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Share my 2-cent.

A VPN has a list of sites, which can be covered by the attribute of a list =
of site under vpn-svc container. This attribute just contains the site refe=
rence.
L3SM needs a site container to cover site attributes because individual sit=
es have different properties.
L3SM needs a vpn-svc per site container that contains the attributes for a =
vpn-svc relevant to a site, i.e. vpn end point at a site.

Using these three containers, we can model a site that can have either sing=
le VPN or multiple VPNs.

Does this make a sense?

Thanks,
Lucy




From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Friday, February 26, 2016 2:28 AM
To: Aijun Wang; Lucy yong; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Again,  in a multiVPN scenario, we have a SINGLE logical site so if you use=
 site under vpn-svc you will have to duplicate all the site information (ro=
uting-protocols, security , ip addressing ...) and it's useless because it =
will be exactly the same. So the model becomes really heavy to use while to=
day it's really flexible.
This duplication is a no GO for me. Now if you go to use a reference to a t=
emplate, it's exactly the same like having a site-list with references only=
 that I proposed, but Michael had a very good argument telling that splitti=
ng the site attributes in two subtree is a very bad idea.

I don't really understand the old argument telling that putting sites under=
 vpn is more service oriented. This is for sure another way to model it, bu=
t the current way is also service oriented but we separate sites and VPN to=
 have the best flexibility in mapping sites to VPNs. Multiple service provi=
ders are using this kind of separation between VPN and sites in their infor=
mation system today (this was one of the first outcomes when we started thi=
s modeling exercice).

Now from an operational point of view (not configuration), people need to e=
asy access the list of sites per VPN, we can create an read-only container =
for that purpose.


From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, February 26, 2016 02:22
To: 'Lucy yong'; l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi, Lucy:

Is it more clear to put the list site within the list vpn-svc? This correla=
te naturally the relationship between vpn id and its associated sites, and =
also the attributes of these sites.
For site that belong to multiple vpn, the site' information will be existed=
 in several specific vpn context. Considering the site's attribute may be v=
ary for different vpn, it is reasonable for the customer.

For site-template container, I propose:
1.  we change it into grouping site-template, and use it within list sites,=
 or
2. define the related items directly  within the list sites and eliminate t=
he site-template container.

Best Regards.

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, February 25, 2016 11:59 PM
To: l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi All,

Current L3vpn service model (the draft) specifies vpn-svc and site containe=
rs only. In order to address multiple vpn at one site, we need vpn-svc per =
site container too. Some attributes under site container should belong to v=
pn-svc per site container such as vpn-policy, service, etc. The site contai=
ner needs to have a parameter "multiplexing" to indicate if a site will hav=
e single vpn or multiple vpn. This will address the issue of multi-vpn at a=
 site discussed in today's interim meeting.

Not sure why need site-template container.

Regards,
Lucy

___________________________________________________________________________=
______________________________________________



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_2691CE0099834E4A9C5044EEC662BB9D5724619Ddfweml701chm_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


Share my 2-cent.


 


A VPN has a list of=
 sites, which can be covered by the attribute of a list of site under vpn-s=
vc container. This attribute just contains the site reference.


L3SM needs a site c=
ontainer to cover site attributes because individual sites have different p=
roperties.


L3SM needs a vpn-sv=
c per site container that contains the attributes for a vpn-svc relevant to=
 a site, i.e. vpn end point at a site.


 


Using these three c=
ontainers, we can model a site that can have either single VPN or multiple =
VPNs.



 


Does this make a se=
nse?


 


Thanks,<=
/span>


Lucy


 


<=
/i>


 


 


 






From: stephane=
.litkowski@orange.com [mailto:stephane.litkowski@orange.com]


Sent: Friday, February 26, 2016 2:28 AM

To: Aijun Wang; Lucy yong; l3sm@ietf.org

Subject: RE: [L3sm] L3 service model suggestion





 


Hi,<=
/p>

 


Again,  in a mult=
iVPN scenario, we have a SINGLE logical site so if you use site under vpn-s=
vc you will have to duplicate all the site information (routing-protocols, =
security , ip addressing …) and it’s useless
 because it will be exactly the same. So the model becomes really heavy to =
use while today it’s really flexible.


This duplication is a =
no GO for me. Now if you go to use a reference to a template, it’s ex=
actly the same like having a site-list with references only that I proposed=
, but Michael had a very good argument telling
 that splitting the site attributes in two subtree is a very bad idea.=



 


I don’t really u=
nderstand the old argument telling that putting sites under vpn is more ser=
vice oriented. This is for sure another way to model it, but the current wa=
y is also service oriented but we separate
 sites and VPN to have the best flexibility in mapping sites to VPNs. Multi=
ple service providers are using this kind of separation between VPN and sit=
es in their information system today (this was one of the first outcomes wh=
en we started this modeling exercice).


 


Now from an operationa=
l point of view (not configuration), people need to easy access the list of=
 sites per VPN, we can create an read-only container for that purpose.=



 


 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of Aijun Wang

Sent: Friday, February 26, 2016 02:22

To: 'Lucy yong'; l3sm@ietf.org<=
br>
Subject: [L3sm] L3 service model suggestion






 


Hi, L=
ucy:


=
 


Is it=
 more clear to put the list site within the list vpn-svc? This correlate na=
turally the relationship between vpn id and its associated sites, and also =
the attributes of these sites.


For s=
ite that belong to multiple vpn, the site’ information will be existe=
d in several specific vpn context. Considering the site’s attribute m=
ay be vary for different vpn, it is reasonable for
 the customer.


=
 


For s=
ite-template container, I propose:


1. &n=
bsp;we change it into grouping site-template, and use it within list sites,=
 or


2. de=
fine the related items directly  within the list sites and eliminate t=
he site-template container.


=
 


Best =
Regards.


=
 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of Lucy yong

Sent: Thursday, February 25, 2016 11:59 PM

To: l3sm@ietf.org

Subject: [L3sm] L3 service model suggestion






 


Hi All,


 


Current L3vpn service model (the draft) specifies vp=
n-svc and site containers only. In order to address multiple vpn at one sit=
e, we need vpn-svc per site container too. Some attributes under site conta=
iner should belong to vpn-svc per
 site container such as vpn-policy, service, etc. The site container needs =
to have a parameter “multiplexing” to indicate if a site will h=
ave single vpn or multiple vpn. This will address the issue of multi-vpn at=
 a site discussed in today’s interim meeting.


 


Not sure why need site-template container.


 


Regards,


Lucy


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.






--_000_2691CE0099834E4A9C5044EEC662BB9D5724619Ddfweml701chm_--


From nobody Fri Feb 26 07:50:04 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC731A924A for ; Fri, 26 Feb 2016 07:50:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.156
X-Spam-Level: 
X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 I9FETkV_4Rtb for ; Fri, 26 Feb 2016 07:49:59 -0800 (PST)
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 E4FF01A92AE for ; Fri, 26 Feb 2016 07:49:58 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJF19035; Fri, 26 Feb 2016 15:49:56 +0000 (GMT)
Received: from lhreml704-cah.china.huawei.com (10.201.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Feb 2016 15:49:55 +0000
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Feb 2016 15:49:55 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Fri, 26 Feb 2016 07:49:37 -0800
From: Lucy yong 
To: Qin Wu , "l3sm@ietf.org" 
Thread-Topic: L3 service model suggestion
Thread-Index: AdFv5NXohY58UF8wRLqEAwIfFWnLNAAXBAtAABqAjhA=
Date: Fri, 26 Feb 2016 15:49:36 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572461D5@dfweml701-chm>
References: <2691CE0099834E4A9C5044EEC662BB9D57245D3B@dfweml701-chm> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.135.10]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D572461D5dfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.56D07424.00D7, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6955d8bc56b3bface32c4f3b618da465
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2016 15:50:02 -0000

--_000_2691CE0099834E4A9C5044EEC662BB9D572461D5dfweml701chm_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgUWluLA0KDQpQbGVhc2Ugc2VlIGJlbG93Lg0KDQpGcm9tOiBRaW4gV3UNClNlbnQ6IFRodXJz
ZGF5LCBGZWJydWFyeSAyNSwgMjAxNiA5OjE1IFBNDQpUbzogTHVjeSB5b25nOyBsM3NtQGlldGYu
b3JnDQpTdWJqZWN0OiBSRTogTDMgc2VydmljZSBtb2RlbCBzdWdnZXN0aW9uDQoNCkhpLCBMdWN5
Og0Kt6K8/sjLOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEx1Y3kg
eW9uZw0Kt6LLzcqxvOQ6IDIwMTbE6jLUwjI1yNUgMjM6NTkNCsrVvP7IyzogbDNzbUBpZXRmLm9y
ZzxtYWlsdG86bDNzbUBpZXRmLm9yZz4NCtb3zOI6IFtMM3NtXSBMMyBzZXJ2aWNlIG1vZGVsIHN1
Z2dlc3Rpb24NCg0KSGkgQWxsLA0KDQpDdXJyZW50IEwzdnBuIHNlcnZpY2UgbW9kZWwgKHRoZSBk
cmFmdCkgc3BlY2lmaWVzIHZwbi1zdmMgYW5kIHNpdGUgY29udGFpbmVycyBvbmx5LiBJbiBvcmRl
ciB0byBhZGRyZXNzIG11bHRpcGxlIHZwbiBhdCBvbmUgc2l0ZSwgd2UgbmVlZCB2cG4tc3ZjIHBl
ciBzaXRlIGNvbnRhaW5lciB0b28uIFNvbWUgYXR0cmlidXRlcyB1bmRlciBzaXRlIGNvbnRhaW5l
ciBzaG91bGQgYmVsb25nIHRvIHZwbi1zdmMgcGVyIHNpdGUgY29udGFpbmVyIHN1Y2ggYXMgdnBu
LXBvbGljeSwgc2VydmljZSwgZXRjLg0KDQpbUWluXTogSSBiZWxpZXZlIHZwbi1wb2xpY3kgaGFz
IGFscmVhZHkgYmVlbiBtb2RlbGVkIGFzIHZwbi1zdmMgcGVyIHNpdGUsIHNlZSBzZWN0aW9uIDUu
Mi4yDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNl
cnZpY2UtbW9kZWwtMDIjc2VjdGlvbi01LjIuMg0KRm9yIHNlcnZpY2UsIHdoYXQgYXJlIGRlZmlu
ZWQgZm9yIHNlcnZpY2UgYXJlIGNvbW1vbiBhdHRyaWJ1dGVzIHRoYXQgYXJlIGFwcGxpZWQgdG8g
YWxsIHRoZSBWUE4gc2VydmljZSBpZiBvbmUgc2l0ZSBiZWxvbmdpbmcgdG8gbXVsdGlwbGUgVlBO
IHNlcnZpY2UuDQpQbGVhc2Ugc2VlIGV4YW1wbGVzIGluIHRoZSBzZWN0aW9uIDUuMi42Lg0KW1tM
dWN5XV0gSSBzZWUgdGhlIGRlc2NyaXB0aW9uLiBCdXQgdGhlIFlBTkcgbW9kdWxlIGluIHNlY3Rp
b24gNSBjYW4gbm90IGNvdmVyIHRoZSBjYXNlIHRoYXQgYSBzaXRlIHRoYXQgYXR0YWNoZXMgdG8g
bXVsdGlwbGUgVlBOcyBhbmQgZGlmZmVyZW50IHNlcnZpY2UgcG9saWNpZXMgZm9yIGluZGl2aWR1
YWwgVlBOcy4gSSB0aGluayB0aGlzIGlzIGNvbW1vbiB1c2UgY2FzZS4NCg0KVGhlIHNpdGUgY29u
dGFpbmVyIG5lZWRzIHRvIGhhdmUgYSBwYXJhbWV0ZXIgobBtdWx0aXBsZXhpbmehsSB0byBpbmRp
Y2F0ZSBpZiBhIHNpdGUgd2lsbCBoYXZlIHNpbmdsZSB2cG4gb3IgbXVsdGlwbGUgdnBuLiBUaGlz
IHdpbGwgYWRkcmVzcyB0aGUgaXNzdWUgb2YgbXVsdGktdnBuIGF0IGEgc2l0ZSBkaXNjdXNzZWQg
aW4gdG9kYXmhr3MgaW50ZXJpbSBtZWV0aW5nLg0KDQpbUWluXTogRm9yIHZwbi1wb2xpY3ksIGl0
IGlzIGltcGxpY2l0bHkgaW5kaWNhdGVkIGJ5IHRoZSBudW1iZXIgb2YgcG9saWN5IGVudHJpZXMu
DQpbW0x1Y3ldXSBJTU86IHdoZXRoZXIgc2l0ZSBhdHRhY2hpbmcgdG8gc2luZ2xlIFZQTiBvciBt
dWx0aXBsZSBWUE5zIGlzIGEgbWFqb3Igc2VydmljZSBwcm9wZXJ0eSwgIGdvb2QgdG8gaGF2ZSBh
biBhdHRyaWJ1dGUgdG8gZGlmZmVyZW50aWF0ZSB0d28gY2FzZXMuIFRoaXMgaXMgcmVsYXRlZCB0
byBzaXRlIGF0dHJpYnV0ZSwgbm90IFZQTi1wb2xpY3kuDQoNCk5vdCBzdXJlIHdoeSBuZWVkIHNp
dGUtdGVtcGxhdGUgY29udGFpbmVyLg0KDQpbUWluXTogU2l0ZS10ZW1wbGF0ZXMgYWxsb3cgdG8g
ZGVmaW5lIGNvbmZpZ3VyYXRpb24gYmxvY2tzIHRoYXQgd2lsbCBiZSAgaW5oZXJpdGVkIGJ5IG9u
ZSBvciBtdWx0aXBsZSBzaXRlcyBpbiBvcmRlciB0byBzcGVlZCB1cA0KICAgY29uZmlndXJhdGlv
bi4gU2VlIG1vcmUgZGV0YWlscyBpbiBzZWN0aW9uIDUuNCBvZiBzZXJ2aWNlIG1vZGVsIGRyYWZ0
Lg0KW1tMdWN5XV0gSSBzdGlsbCBkb26hr3Qga25vdyB0aGUgdmFsdWUgb2YgaXQgeWV0LiBJIHdp
bGwgcmVhZCBtb3JlIGFuZCBsZWFybi4gOikNCg0KVGhhbmtzLA0KTHVjeQ0KDQpSZWdhcmRzLA0K
THVjeQ0K

--_000_2691CE0099834E4A9C5044EEC662BB9D572461D5dfweml701chm_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi Qin,<=
/span>


 


Please see below.


 






From: Qin Wu


Sent: Thursday, February 25, 2016 9:15 PM

To: Lucy yong; l3sm@ietf.org

Subject: RE: L3 service model suggestion






 


Hi, L=
ucy:






=B7=A2=BC=FE=C8=CB: L3sm [mailto:l3sm=
-bounces@ietf.org]
=B4=FA=B1=ED
Lucy yong
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA=
2=
=D4=C225<=
span lang=3D"ZH-CN" style=3D"font-size:10.0pt;font-family:SimSun">=C8=D5
 23:59

=CA=D5=BC=FE=C8=CB:
l3sm@ietf.org

=D6=F7=CC=E2: [L3sm=
] L3 service model suggestion






 


Hi All,


 


Current L3vpn service model (the draft) specifies vp=
n-svc and site containers only. In order to address multiple vpn at one sit=
e, we need vpn-svc per site container too. Some attributes under site conta=
iner should belong to vpn-svc per
 site container such as vpn-policy, service, etc. 


=
 


[Qin]=
: I believe vpn-policy has already been modeled as vpn-svc per site, see se=
ction 5.2.2


https://tools.ietf.org/html/draft-ietf-l3sm-l3vpn-service-mode=
l-02#section-5.2.2


For s=
ervice, what are defined for service are common attributes that are applied=
 to all the VPN service if one site belonging to multiple VPN service.=



Pleas=
e see examples in the section 5.2.6.


[[Lucy]] I see t=
he description. But the YANG module in section 5 can not cover the case tha=
t a site that attaches to multiple VPNs and different service policies for =
individual VPNs. I think this is common
 use case. 


=
 


The site container needs to have a parameter =A1=B0m=
ultiplexing=A1=B1 to indicate if a site will have single vpn or multiple vp=
n. This will address the issue of multi-vpn at a site discussed in today=A1=
=AFs interim meeting.


 


[Qin]=
: For vpn-policy, it is implicitly indicated by the number of policy entrie=
s.


[[Lucy]] IMO: wh=
ether site attaching to single VPN or multiple VPNs is a major service prop=
erty,  good to have an attribute to differentiate two cases. This is r=
elated to site attribute, not VPN-policy.


=
 


Not sure why need site-template container.


 


[Qin]=
: Site-templates allow to define configuration blocks that will be  in=
herited by one or multiple sites in order to speed up


 =
;  configuration. See more details in section 5.4 of service model dra=
ft.


[[Lucy]] I still=
 don=A1=AFt know the value of it yet. I will read more and learn.
J<=
/span>   <=
/span>


 


Thanks,


Lucy =



=
 


Regards,


Lucy






--_000_2691CE0099834E4A9C5044EEC662BB9D572461D5dfweml701chm_--


From nobody Fri Feb 26 08:01:17 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B218F1ABD8F for ; Fri, 26 Feb 2016 08:01:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.606
X-Spam-Level: 
X-Spam-Status: No, score=-3.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 8HX0HuP4F8jh for ; Fri, 26 Feb 2016 08:01:04 -0800 (PST)
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 2B8A91A7028 for ; Fri, 26 Feb 2016 08:01:03 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJF20353; Fri, 26 Feb 2016 16:00:59 +0000 (GMT)
Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Feb 2016 16:00:55 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Fri, 26 Feb 2016 08:00:36 -0800
From: Lucy yong 
To: "stephane.litkowski@orange.com" , "Aijun Wang" <13301168517@189.cn>, "l3sm@ietf.org" 
Thread-Topic: [L3sm]  L3 service model suggestion
Thread-Index: AQHRcDQlKf5V3VVA60qHAvxleY5vDJ89/NjwgABxxpCAAI53AP//fYOA
Date: Fri, 26 Feb 2016 16:00:35 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572461F1@dfweml701-chm>
References: <005001d17034$26bb1460$74313d20$@cn> <28091_1456475302_56D00CA6_28091_2131_1_9E32478DFA9976438E7A22F69B08FF92168CDD59@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D5724619D@dfweml701-chm> <26279_1456501089_56D07161_26279_1306_1_9E32478DFA9976438E7A22F69B08FF92168CF246@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <26279_1456501089_56D07161_26279_1306_1_9E32478DFA9976438E7A22F69B08FF92168CF246@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.135.111]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D572461F1dfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56D076BC.0016, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 25e477c285de2d9f704cfbb45a64624b
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2016 16:01:15 -0000

--_000_2691CE0099834E4A9C5044EEC662BB9D572461F1dfweml701chm_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Stephane, et al,

I did not understand Michael's previous mail. So just give my opinion. Than=
k you to point out his concern.

IMO: Our goal here is to work out the model that can cover common L3 VPN se=
rvices. If a site attaching to multiple VPNs is a common use case, we need =
to address it. We want to have one service model to cover single VPN and mu=
ltiple VPN at a site too. I don't see that two list entries is a problem to=
 concern here.

Regards,
Lucy



From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Friday, February 26, 2016 9:38 AM
To: Lucy yong; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Yes this works but this was identified by Michael Scharf as an issue, see m=
ail attached


"would require two different list entries to be present before a site can a=
ctually be configured. I would prefer to void such dependencies as far as p=
ossible, in order to simplify the use of the model and avoid internal incon=
sistencies."


From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Friday, February 26, 2016 16:27
To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Share my 2-cent.

A VPN has a list of sites, which can be covered by the attribute of a list =
of site under vpn-svc container. This attribute just contains the site refe=
rence.
L3SM needs a site container to cover site attributes because individual sit=
es have different properties.
L3SM needs a vpn-svc per site container that contains the attributes for a =
vpn-svc relevant to a site, i.e. vpn end point at a site.

Using these three containers, we can model a site that can have either sing=
le VPN or multiple VPNs.

Does this make a sense?

Thanks,
Lucy





From: stephane.litkowski@orange.com [=
mailto:stephane.litkowski@orange.com]
Sent: Friday, February 26, 2016 2:28 AM
To: Aijun Wang; Lucy yong; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Again,  in a multiVPN scenario, we have a SINGLE logical site so if you use=
 site under vpn-svc you will have to duplicate all the site information (ro=
uting-protocols, security , ip addressing ...) and it's useless because it =
will be exactly the same. So the model becomes really heavy to use while to=
day it's really flexible.
This duplication is a no GO for me. Now if you go to use a reference to a t=
emplate, it's exactly the same like having a site-list with references only=
 that I proposed, but Michael had a very good argument telling that splitti=
ng the site attributes in two subtree is a very bad idea.

I don't really understand the old argument telling that putting sites under=
 vpn is more service oriented. This is for sure another way to model it, bu=
t the current way is also service oriented but we separate sites and VPN to=
 have the best flexibility in mapping sites to VPNs. Multiple service provi=
ders are using this kind of separation between VPN and sites in their infor=
mation system today (this was one of the first outcomes when we started thi=
s modeling exercice).

Now from an operational point of view (not configuration), people need to e=
asy access the list of sites per VPN, we can create an read-only container =
for that purpose.


From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, February 26, 2016 02:22
To: 'Lucy yong'; l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi, Lucy:

Is it more clear to put the list site within the list vpn-svc? This correla=
te naturally the relationship between vpn id and its associated sites, and =
also the attributes of these sites.
For site that belong to multiple vpn, the site' information will be existed=
 in several specific vpn context. Considering the site's attribute may be v=
ary for different vpn, it is reasonable for the customer.

For site-template container, I propose:
1.  we change it into grouping site-template, and use it within list sites,=
 or
2. define the related items directly  within the list sites and eliminate t=
he site-template container.

Best Regards.

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, February 25, 2016 11:59 PM
To: l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi All,

Current L3vpn service model (the draft) specifies vpn-svc and site containe=
rs only. In order to address multiple vpn at one site, we need vpn-svc per =
site container too. Some attributes under site container should belong to v=
pn-svc per site container such as vpn-policy, service, etc. The site contai=
ner needs to have a parameter "multiplexing" to indicate if a site will hav=
e single vpn or multiple vpn. This will address the issue of multi-vpn at a=
 site discussed in today's interim meeting.

Not sure why need site-template container.

Regards,
Lucy

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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_2691CE0099834E4A9C5044EEC662BB9D572461F1dfweml701chm_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Stephane, et al,=



 


I did not understan=
d Michael’s previous mail. So just give my opinion. Thank you to poin=
t out his concern.


 


IMO: Our goal here =
is to work out the model that can cover common L3 VPN services. If a site a=
ttaching to multiple VPNs is a common use case, we need to address it. We w=
ant to have one service model to cover
 single VPN and multiple VPN at a site too. I don’t see that two list=
 entries is a problem to concern here.


 


Regards,=



Lucy


 


 


 






From: stephane=
.litkowski@orange.com [mailto:stephane.litkowski@orange.com]


Sent: Friday, February 26, 2016 9:38 AM

To: Lucy yong; Aijun Wang; l3sm@ietf.org

Subject: RE: [L3sm] L3 service model suggestion





 


Yes this works but thi=
s was identified by Michael Scharf as an issue, see mail attached


 


“would=
 require two different list entries to be present before a site can actuall=
y be configured. I would prefer to void such dependencies as far as possibl=
e, in order to simplify the use of the model
 and avoid internal inconsistencies.”


 


 






From: Lucy yon=
g [mailto:lucy.yong@huawei.com]


Sent: Friday, February 26, 2016 16:27

To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; 
l3sm@ietf.org

Subject: RE: [L3sm] L3 service model suggestion





 


Hi,


 


Share my 2-cent.


 


A VPN has a list of=
 sites, which can be covered by the attribute of a list of site under vpn-s=
vc container. This attribute just contains the site reference.


L3SM needs a site c=
ontainer to cover site attributes because individual sites have different p=
roperties.


L3SM needs a vpn-sv=
c per site container that contains the attributes for a vpn-svc relevant to=
 a site, i.e. vpn end point at a site.


 


Using these three c=
ontainers, we can model a site that can have either single VPN or multiple =
VPNs.



 


Does this make a se=
nse?


 


Thanks,<=
/span>


Lucy


 


 


 


 


 






From:
stephane.litkowski@orange.=
com [mailto:stephane.l=
itkowski@orange.com]


Sent: Friday, February 26, 2016 2:28 AM

To: Aijun Wang; Lucy yong; l3sm@iet=
f.org

Subject: RE: [L3sm] L3 service model suggestion





 


Hi,<=
/p>

 


Again,  in a mult=
iVPN scenario, we have a SINGLE logical site so if you use site under vpn-s=
vc you will have to duplicate all the site information (routing-protocols, =
security , ip addressing …) and it’s useless
 because it will be exactly the same. So the model becomes really heavy to =
use while today it’s really flexible.


This duplication is a =
no GO for me. Now if you go to use a reference to a template, it’s ex=
actly the same like having a site-list with references only that I proposed=
, but Michael had a very good argument telling
 that splitting the site attributes in two subtree is a very bad idea.=



 


I don’t really u=
nderstand the old argument telling that putting sites under vpn is more ser=
vice oriented. This is for sure another way to model it, but the current wa=
y is also service oriented but we separate
 sites and VPN to have the best flexibility in mapping sites to VPNs. Multi=
ple service providers are using this kind of separation between VPN and sit=
es in their information system today (this was one of the first outcomes wh=
en we started this modeling exercice).


 


Now from an operationa=
l point of view (not configuration), people need to easy access the list of=
 sites per VPN, we can create an read-only container for that purpose.=



 


 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of Aijun Wang

Sent: Friday, February 26, 2016 02:22

To: 'Lucy yong'; l3sm@ietf.org<=
br>
Subject: [L3sm] L3 service model suggestion






 


Hi, L=
ucy:


=
 


Is it=
 more clear to put the list site within the list vpn-svc? This correlate na=
turally the relationship between vpn id and its associated sites, and also =
the attributes of these sites.


For s=
ite that belong to multiple vpn, the site’ information will be existe=
d in several specific vpn context. Considering the site’s attribute m=
ay be vary for different vpn, it is reasonable for
 the customer.


=
 


For s=
ite-template container, I propose:


1. &n=
bsp;we change it into grouping site-template, and use it within list sites,=
 or


2. de=
fine the related items directly  within the list sites and eliminate t=
he site-template container.


=
 


Best =
Regards.


=
 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of Lucy yong

Sent: Thursday, February 25, 2016 11:59 PM

To: l3sm@ietf.org

Subject: [L3sm] L3 service model suggestion






 


Hi All,


 


Current L3vpn service model (the draft) specifies vp=
n-svc and site containers only. In order to address multiple vpn at one sit=
e, we need vpn-svc per site container too. Some attributes under site conta=
iner should belong to vpn-svc per
 site container such as vpn-policy, service, etc. The site container needs =
to have a parameter “multiplexing” to indicate if a site will h=
ave single vpn or multiple vpn. This will address the issue of multi-vpn at=
 a site discussed in today’s interim meeting.


 


Not sure why need site-template container.


 


Regards,


Lucy


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.






--_000_2691CE0099834E4A9C5044EEC662BB9D572461F1dfweml701chm_--


From nobody Fri Feb 26 08:12:29 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE65B1ACAD4 for ; Fri, 26 Feb 2016 08:12:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.304
X-Spam-Level: 
X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 NcIBbGNmc4bx for ; Fri, 26 Feb 2016 08:12:22 -0800 (PST)
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 BCFC21AC7E7 for ; Fri, 26 Feb 2016 08:12:21 -0800 (PST)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 3ECAE2014C; Fri, 26 Feb 2016 17:12:20 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 0C6CA1A0076; Fri, 26 Feb 2016 17:12:20 +0100 (CET)
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; Fri, 26 Feb 2016 17:12:19 +0100
From: 
To: Lucy yong , Aijun Wang <13301168517@189.cn>, "l3sm@ietf.org" , "SCHARF, Michael (Michael) (michael.scharf@nokia.com)" 
Thread-Topic: [L3sm]  L3 service model suggestion
Thread-Index: AQHRcK7ff7VxwXyzkU2jl5DUB9OT5Z8+fp2A
Date: Fri, 26 Feb 2016 16:12:19 +0000
Message-ID: <24712_1456503140_56D07964_24712_11500_1_9E32478DFA9976438E7A22F69B08FF92168CF4AA@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <005001d17034$26bb1460$74313d20$@cn> <28091_1456475302_56D00CA6_28091_2131_1_9E32478DFA9976438E7A22F69B08FF92168CDD59@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D5724619D@dfweml701-chm> <26279_1456501089_56D07161_26279_1306_1_9E32478DFA9976438E7A22F69B08FF92168CF246@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D572461F1@dfweml701-chm>
In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572461F1@dfweml701-chm>
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: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92168CF4AAOPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2016 16:12:28 -0000

--_000_9E32478DFA9976438E7A22F69B08FF92168CF4AAOPEXCLILMA4corp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From a service design point of view, it works for me. But I'm not an implem=
entor, so there may be some implementation constraints/requirement that we =
need also to take care of : so I cannot really go against Michael who provi=
ded an implementation view point.

Michael,

May be can you elaborate on the constraints you see by introducing a list o=
f sites (just references) in the vpn-svc container ? Is it strong or not ?

Thx


From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Friday, February 26, 2016 17:01
To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi Stephane, et al,

I did not understand Michael's previous mail. So just give my opinion. Than=
k you to point out his concern.

IMO: Our goal here is to work out the model that can cover common L3 VPN se=
rvices. If a site attaching to multiple VPNs is a common use case, we need =
to address it. We want to have one service model to cover single VPN and mu=
ltiple VPN at a site too. I don't see that two list entries is a problem to=
 concern here.

Regards,
Lucy



From: stephane.litkowski@orange.com [=
mailto:stephane.litkowski@orange.com]
Sent: Friday, February 26, 2016 9:38 AM
To: Lucy yong; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Yes this works but this was identified by Michael Scharf as an issue, see m=
ail attached


"would require two different list entries to be present before a site can a=
ctually be configured. I would prefer to void such dependencies as far as p=
ossible, in order to simplify the use of the model and avoid internal incon=
sistencies."


From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Friday, February 26, 2016 16:27
To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Share my 2-cent.

A VPN has a list of sites, which can be covered by the attribute of a list =
of site under vpn-svc container. This attribute just contains the site refe=
rence.
L3SM needs a site container to cover site attributes because individual sit=
es have different properties.
L3SM needs a vpn-svc per site container that contains the attributes for a =
vpn-svc relevant to a site, i.e. vpn end point at a site.

Using these three containers, we can model a site that can have either sing=
le VPN or multiple VPNs.

Does this make a sense?

Thanks,
Lucy





From: stephane.litkowski@orange.com [=
mailto:stephane.litkowski@orange.com]
Sent: Friday, February 26, 2016 2:28 AM
To: Aijun Wang; Lucy yong; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Again,  in a multiVPN scenario, we have a SINGLE logical site so if you use=
 site under vpn-svc you will have to duplicate all the site information (ro=
uting-protocols, security , ip addressing ...) and it's useless because it =
will be exactly the same. So the model becomes really heavy to use while to=
day it's really flexible.
This duplication is a no GO for me. Now if you go to use a reference to a t=
emplate, it's exactly the same like having a site-list with references only=
 that I proposed, but Michael had a very good argument telling that splitti=
ng the site attributes in two subtree is a very bad idea.

I don't really understand the old argument telling that putting sites under=
 vpn is more service oriented. This is for sure another way to model it, bu=
t the current way is also service oriented but we separate sites and VPN to=
 have the best flexibility in mapping sites to VPNs. Multiple service provi=
ders are using this kind of separation between VPN and sites in their infor=
mation system today (this was one of the first outcomes when we started thi=
s modeling exercice).

Now from an operational point of view (not configuration), people need to e=
asy access the list of sites per VPN, we can create an read-only container =
for that purpose.


From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, February 26, 2016 02:22
To: 'Lucy yong'; l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi, Lucy:

Is it more clear to put the list site within the list vpn-svc? This correla=
te naturally the relationship between vpn id and its associated sites, and =
also the attributes of these sites.
For site that belong to multiple vpn, the site' information will be existed=
 in several specific vpn context. Considering the site's attribute may be v=
ary for different vpn, it is reasonable for the customer.

For site-template container, I propose:
1.  we change it into grouping site-template, and use it within list sites,=
 or
2. define the related items directly  within the list sites and eliminate t=
he site-template container.

Best Regards.

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, February 25, 2016 11:59 PM
To: l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi All,

Current L3vpn service model (the draft) specifies vpn-svc and site containe=
rs only. In order to address multiple vpn at one site, we need vpn-svc per =
site container too. Some attributes under site container should belong to v=
pn-svc per site container such as vpn-policy, service, etc. The site contai=
ner needs to have a parameter "multiplexing" to indicate if a site will hav=
e single vpn or multiple vpn. This will address the issue of multi-vpn at a=
 site discussed in today's interim meeting.

Not sure why need site-template container.

Regards,
Lucy

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________

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_9E32478DFA9976438E7A22F69B08FF92168CF4AAOPEXCLILMA4corp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











From a service design =
point of view, it works for me. But I’m not an implementor, so there =
may be some implementation constraints/requirement that we need also to tak=
e care of : so I cannot really go against
 Michael who provided an implementation view point.


 


Michael,


 


May be can you elabora=
te on the constraints you see by introducing a list of sites (just referenc=
es) in the vpn-svc container ? Is it strong or not ?


 


Thx<=
/p>

 


 






From: Lucy yon=
g [mailto:lucy.yong@huawei.com]


Sent: Friday, February 26, 2016 17:01

To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; l3sm@ietf.org

Subject: RE: [L3sm] L3 service model suggestion






 


Hi Stephane, et al,=



 


I did not understan=
d Michael’s previous mail. So just give my opinion. Thank you to poin=
t out his concern.


 


IMO: Our goal here =
is to work out the model that can cover common L3 VPN services. If a site a=
ttaching to multiple VPNs is a common use case, we need to address it. We w=
ant to have one service model to cover
 single VPN and multiple VPN at a site too. I don’t see that two list=
 entries is a problem to concern here.


 


Regards,=



Lucy


 


 


 






From:
stephane.litkowski@orange.=
com [mailto:stephane.l=
itkowski@orange.com]


Sent: Friday, February 26, 2016 9:38 AM

To: Lucy yong; Aijun Wang; l3sm@iet=
f.org

Subject: RE: [L3sm] L3 service model suggestion






 


Yes this works but thi=
s was identified by Michael Scharf as an issue, see mail attached


 


“would=
 require two different list entries to be present before a site can actuall=
y be configured. I would prefer to void such dependencies as far as possibl=
e, in order to simplify the use of the model
 and avoid internal inconsistencies.”


 


 






From: Lucy yon=
g [mailto:lucy.yong@huawei.com]


Sent: Friday, February 26, 2016 16:27

To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; 
l3sm@ietf.org

Subject: RE: [L3sm] L3 service model suggestion






 


Hi,


 


Share my 2-cent.


 


A VPN has a list of=
 sites, which can be covered by the attribute of a list of site under vpn-s=
vc container. This attribute just contains the site reference.


L3SM needs a site c=
ontainer to cover site attributes because individual sites have different p=
roperties.


L3SM needs a vpn-sv=
c per site container that contains the attributes for a vpn-svc relevant to=
 a site, i.e. vpn end point at a site.


 


Using these three c=
ontainers, we can model a site that can have either single VPN or multiple =
VPNs.



 


Does this make a se=
nse?


 


Thanks,<=
/span>


Lucy


 


 


 


 


 






From:
stephane.litkowski@orange.=
com [mailto:stephane.l=
itkowski@orange.com]


Sent: Friday, February 26, 2016 2:28 AM

To: Aijun Wang; Lucy yong; l3sm@iet=
f.org

Subject: RE: [L3sm] L3 service model suggestion






 


Hi,<=
/p>

 


Again,  in a mult=
iVPN scenario, we have a SINGLE logical site so if you use site under vpn-s=
vc you will have to duplicate all the site information (routing-protocols, =
security , ip addressing …) and it’s useless
 because it will be exactly the same. So the model becomes really heavy to =
use while today it’s really flexible.


This duplication is a =
no GO for me. Now if you go to use a reference to a template, it’s ex=
actly the same like having a site-list with references only that I proposed=
, but Michael had a very good argument telling
 that splitting the site attributes in two subtree is a very bad idea.=



 


I don’t really u=
nderstand the old argument telling that putting sites under vpn is more ser=
vice oriented. This is for sure another way to model it, but the current wa=
y is also service oriented but we separate
 sites and VPN to have the best flexibility in mapping sites to VPNs. Multi=
ple service providers are using this kind of separation between VPN and sit=
es in their information system today (this was one of the first outcomes wh=
en we started this modeling exercice).


 


Now from an operationa=
l point of view (not configuration), people need to easy access the list of=
 sites per VPN, we can create an read-only container for that purpose.=



 


 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of Aijun Wang

Sent: Friday, February 26, 2016 02:22

To: 'Lucy yong'; l3sm@ietf.org<=
br>
Subject: [L3sm] L3 service model suggestion






 


Hi, L=
ucy:


=
 


Is it=
 more clear to put the list site within the list vpn-svc? This correlate na=
turally the relationship between vpn id and its associated sites, and also =
the attributes of these sites.


For s=
ite that belong to multiple vpn, the site’ information will be existe=
d in several specific vpn context. Considering the site’s attribute m=
ay be vary for different vpn, it is reasonable for
 the customer.


=
 


For s=
ite-template container, I propose:


1. &n=
bsp;we change it into grouping site-template, and use it within list sites,=
 or


2. de=
fine the related items directly  within the list sites and eliminate t=
he site-template container.


=
 


Best =
Regards.


=
 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of Lucy yong

Sent: Thursday, February 25, 2016 11:59 PM

To: l3sm@ietf.org

Subject: [L3sm] L3 service model suggestion






 


Hi All,


 


Current L3vpn service model (the draft) specifies vp=
n-svc and site containers only. In order to address multiple vpn at one sit=
e, we need vpn-svc per site container too. Some attributes under site conta=
iner should belong to vpn-svc per
 site container such as vpn-policy, service, etc. The site container needs =
to have a parameter “multiplexing” to indicate if a site will h=
ave single vpn or multiple vpn. This will address the issue of multi-vpn at=
 a site discussed in today’s interim meeting.


 


Not sure why need site-template container.


 


Regards,


Lucy


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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


From nobody Fri Feb 26 08:38:03 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7981ACE31 for ; Fri, 26 Feb 2016 08:38:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.3
X-Spam-Level: 
X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 QyHJji1Pdgtb for ; Fri, 26 Feb 2016 08:37:51 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 BC3D51ACE42 for ; Fri, 26 Feb 2016 08:37:50 -0800 (PST)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D0349758C89A6; Fri, 26 Feb 2016 16:37:45 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1QGbmG8024934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Feb 2016 16:37:48 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1QGbkm5018825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Feb 2016 17:37:47 +0100
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.15]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 26 Feb 2016 17:37:46 +0100
From: "Scharf, Michael (Nokia - DE)" 
To: "EXT stephane.litkowski@orange.com" , "Lucy yong" , Aijun Wang <13301168517@189.cn>, "l3sm@ietf.org" 
Thread-Topic: [L3sm] L3 service model suggestion
Thread-Index: AQHRcG+vZvec0LHPr0a57SF/ORFoxJ8+Yr2AgAADAQCAAAZGgIAAA0eAgAATQmA=
Date: Fri, 26 Feb 2016 16:37:45 +0000
Message-ID: <655C07320163294895BBADA28372AF5D486D0D92@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <005001d17034$26bb1460$74313d20$@cn> <28091_1456475302_56D00CA6_28091_2131_1_9E32478DFA9976438E7A22F69B08FF92168CDD59@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D5724619D@dfweml701-chm> <26279_1456501089_56D07161_26279_1306_1_9E32478DFA9976438E7A22F69B08FF92168CF246@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D572461F1@dfweml701-chm> <24712_1456503140_56D07964_24712_11500_1_9E32478DFA9976438E7A22F69B08FF92168CF4AA@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <24712_1456503140_56D07964_24712_11500_1_9E32478DFA9976438E7A22F69B08FF92168CF4AA@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D486D0D92FR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2016 16:38:02 -0000

--_000_655C07320163294895BBADA28372AF5D486D0D92FR712WXCHMBA15z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

For what it is worth, I am a bit surprised by this discussion on optimizing=
 the model for the multiVPN use case. I am not really aware of a strong int=
erest in this particular use case, but obviously this depends on usage and =
deployment scenarios.

I'd suggest to keep the model simple for the case of a single VPN. For the =
vanilla L3VPN use case it would be good to avoid having to manipulate multi=
ple lists, maintain cross-references, etc. Maybe this can be achieved my ma=
king all model components only required for multi VPN optional? KISS princi=
ple...

Michael



From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of EXT stephane.litkows=
ki@orange.com
Sent: Friday, February 26, 2016 5:12 PM
To: Lucy yong; Aijun Wang; l3sm@ietf.org; Scharf, Michael (Nokia - DE)
Subject: Re: [L3sm] L3 service model suggestion

>From a service design point of view, it works for me. But I'm not an implem=
entor, so there may be some implementation constraints/requirement that we =
need also to take care of : so I cannot really go against Michael who provi=
ded an implementation view point.

Michael,

May be can you elaborate on the constraints you see by introducing a list o=
f sites (just references) in the vpn-svc container ? Is it strong or not ?

Thx


From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Friday, February 26, 2016 17:01
To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi Stephane, et al,

I did not understand Michael's previous mail. So just give my opinion. Than=
k you to point out his concern.

IMO: Our goal here is to work out the model that can cover common L3 VPN se=
rvices. If a site attaching to multiple VPNs is a common use case, we need =
to address it. We want to have one service model to cover single VPN and mu=
ltiple VPN at a site too. I don't see that two list entries is a problem to=
 concern here.

Regards,
Lucy



From: stephane.litkowski@orange.com [=
mailto:stephane.litkowski@orange.com]
Sent: Friday, February 26, 2016 9:38 AM
To: Lucy yong; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Yes this works but this was identified by Michael Scharf as an issue, see m=
ail attached


"would require two different list entries to be present before a site can a=
ctually be configured. I would prefer to void such dependencies as far as p=
ossible, in order to simplify the use of the model and avoid internal incon=
sistencies."


From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Friday, February 26, 2016 16:27
To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Share my 2-cent.

A VPN has a list of sites, which can be covered by the attribute of a list =
of site under vpn-svc container. This attribute just contains the site refe=
rence.
L3SM needs a site container to cover site attributes because individual sit=
es have different properties.
L3SM needs a vpn-svc per site container that contains the attributes for a =
vpn-svc relevant to a site, i.e. vpn end point at a site.

Using these three containers, we can model a site that can have either sing=
le VPN or multiple VPNs.

Does this make a sense?

Thanks,
Lucy





From: stephane.litkowski@orange.com [=
mailto:stephane.litkowski@orange.com]
Sent: Friday, February 26, 2016 2:28 AM
To: Aijun Wang; Lucy yong; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Again,  in a multiVPN scenario, we have a SINGLE logical site so if you use=
 site under vpn-svc you will have to duplicate all the site information (ro=
uting-protocols, security , ip addressing ...) and it's useless because it =
will be exactly the same. So the model becomes really heavy to use while to=
day it's really flexible.
This duplication is a no GO for me. Now if you go to use a reference to a t=
emplate, it's exactly the same like having a site-list with references only=
 that I proposed, but Michael had a very good argument telling that splitti=
ng the site attributes in two subtree is a very bad idea.

I don't really understand the old argument telling that putting sites under=
 vpn is more service oriented. This is for sure another way to model it, bu=
t the current way is also service oriented but we separate sites and VPN to=
 have the best flexibility in mapping sites to VPNs. Multiple service provi=
ders are using this kind of separation between VPN and sites in their infor=
mation system today (this was one of the first outcomes when we started thi=
s modeling exercice).

Now from an operational point of view (not configuration), people need to e=
asy access the list of sites per VPN, we can create an read-only container =
for that purpose.


From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, February 26, 2016 02:22
To: 'Lucy yong'; l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi, Lucy:

Is it more clear to put the list site within the list vpn-svc? This correla=
te naturally the relationship between vpn id and its associated sites, and =
also the attributes of these sites.
For site that belong to multiple vpn, the site' information will be existed=
 in several specific vpn context. Considering the site's attribute may be v=
ary for different vpn, it is reasonable for the customer.

For site-template container, I propose:
1.  we change it into grouping site-template, and use it within list sites,=
 or
2. define the related items directly  within the list sites and eliminate t=
he site-template container.

Best Regards.

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, February 25, 2016 11:59 PM
To: l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi All,

Current L3vpn service model (the draft) specifies vpn-svc and site containe=
rs only. In order to address multiple vpn at one site, we need vpn-svc per =
site container too. Some attributes under site container should belong to v=
pn-svc per site container such as vpn-policy, service, etc. The site contai=
ner needs to have a parameter "multiplexing" to indicate if a site will hav=
e single vpn or multiple vpn. This will address the issue of multi-vpn at a=
 site discussed in today's interim meeting.

Not sure why need site-template container.

Regards,
Lucy

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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_655C07320163294895BBADA28372AF5D486D0D92FR712WXCHMBA15z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











For what it is worth, =
I am a bit surprised by this discussion on optimizing the model for the mul=
tiVPN use case. I am not really aware of a strong interest in this particul=
ar use case, but obviously this depends
 on usage and deployment scenarios. 


 


I’d suggest to k=
eep the model simple for the case of a single VPN. For the vanilla L3VPN us=
e case it would be good to avoid having to manipulate multiple lists, maint=
ain cross-references, etc. Maybe this can
 be achieved my making all model components only required for multi VPN opt=
ional? KISS principle…


 


Michael


 


 


 






From: L3sm [ma=
ilto:l3sm-bounces@ietf.org]
On Behalf Of EXT stephane.litkowski@orange.com

Sent: Friday, February 26, 2016 5:12 PM

To: Lucy yong; Aijun Wang; l3sm@ietf.org; Scharf, Michael (Nokia - D=
E)

Subject: Re: [L3sm] L3 service model suggestion





 


From a service design =
point of view, it works for me. But I’m not an implementor, so there =
may be some implementation constraints/requirement that we need also to tak=
e care of : so I cannot really go against
 Michael who provided an implementation view point.


 


Michael,


 


May be can you elabora=
te on the constraints you see by introducing a list of sites (just referenc=
es) in the vpn-svc container ? Is it strong or not ?


 


Thx<=
/p>

 


 






From: Lucy yon=
g [mailto:lucy.yong@huawei.com]


Sent: Friday, February 26, 2016 17:01

To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; 
l3sm@ietf.org

Subject: RE: [L3sm] L3 service model suggestion





 


Hi Stephane, et al,=



 


I did not understan=
d Michael’s previous mail. So just give my opinion. Thank you to poin=
t out his concern.


 


IMO: Our goal here =
is to work out the model that can cover common L3 VPN services. If a site a=
ttaching to multiple VPNs is a common use case, we need to address it. We w=
ant to have one service model to cover
 single VPN and multiple VPN at a site too. I don’t see that two list=
 entries is a problem to concern here.


 


Regards,=



Lucy


 


 


 






From:
stephane.litkowski@orange.=
com [mailto:stephane.l=
itkowski@orange.com]


Sent: Friday, February 26, 2016 9:38 AM

To: Lucy yong; Aijun Wang; l3sm@iet=
f.org

Subject: RE: [L3sm] L3 service model suggestion





 


Yes this works but thi=
s was identified by Michael Scharf as an issue, see mail attached


 


“would=
 require two different list entries to be present before a site can actuall=
y be configured. I would prefer to void such dependencies as far as possibl=
e, in order to simplify the use of the model
 and avoid internal inconsistencies.”


 


 






From: Lucy yon=
g [mailto:lucy.yong@huawei.com]


Sent: Friday, February 26, 2016 16:27

To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; 
l3sm@ietf.org

Subject: RE: [L3sm] L3 service model suggestion





 


Hi,


 


Share my 2-cent.


 


A VPN has a list of=
 sites, which can be covered by the attribute of a list of site under vpn-s=
vc container. This attribute just contains the site reference.


L3SM needs a site c=
ontainer to cover site attributes because individual sites have different p=
roperties.


L3SM needs a vpn-sv=
c per site container that contains the attributes for a vpn-svc relevant to=
 a site, i.e. vpn end point at a site.


 


Using these three c=
ontainers, we can model a site that can have either single VPN or multiple =
VPNs.



 


Does this make a se=
nse?


 


Thanks,<=
/span>


Lucy


 


 


 


 


 






From:
stephane.litkowski@orange.=
com [mailto:stephane.l=
itkowski@orange.com]


Sent: Friday, February 26, 2016 2:28 AM

To: Aijun Wang; Lucy yong; l3sm@iet=
f.org

Subject: RE: [L3sm] L3 service model suggestion





 


Hi,<=
/p>

 


Again,  in a mult=
iVPN scenario, we have a SINGLE logical site so if you use site under vpn-s=
vc you will have to duplicate all the site information (routing-protocols, =
security , ip addressing …) and it’s useless
 because it will be exactly the same. So the model becomes really heavy to =
use while today it’s really flexible.


This duplication is a =
no GO for me. Now if you go to use a reference to a template, it’s ex=
actly the same like having a site-list with references only that I proposed=
, but Michael had a very good argument telling
 that splitting the site attributes in two subtree is a very bad idea.=



 


I don’t really u=
nderstand the old argument telling that putting sites under vpn is more ser=
vice oriented. This is for sure another way to model it, but the current wa=
y is also service oriented but we separate
 sites and VPN to have the best flexibility in mapping sites to VPNs. Multi=
ple service providers are using this kind of separation between VPN and sit=
es in their information system today (this was one of the first outcomes wh=
en we started this modeling exercice).


 


Now from an operationa=
l point of view (not configuration), people need to easy access the list of=
 sites per VPN, we can create an read-only container for that purpose.=



 


 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of Aijun Wang

Sent: Friday, February 26, 2016 02:22

To: 'Lucy yong'; l3sm@ietf.org<=
br>
Subject: [L3sm] L3 service model suggestion






 


Hi, L=
ucy:


=
 


Is it=
 more clear to put the list site within the list vpn-svc? This correlate na=
turally the relationship between vpn id and its associated sites, and also =
the attributes of these sites.


For s=
ite that belong to multiple vpn, the site’ information will be existe=
d in several specific vpn context. Considering the site’s attribute m=
ay be vary for different vpn, it is reasonable for
 the customer.


=
 


For s=
ite-template container, I propose:


1. &n=
bsp;we change it into grouping site-template, and use it within list sites,=
 or


2. de=
fine the related items directly  within the list sites and eliminate t=
he site-template container.


=
 


Best =
Regards.


=
 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of Lucy yong

Sent: Thursday, February 25, 2016 11:59 PM

To: l3sm@ietf.org

Subject: [L3sm] L3 service model suggestion






 


Hi All,


 


Current L3vpn service model (the draft) specifies vp=
n-svc and site containers only. In order to address multiple vpn at one sit=
e, we need vpn-svc per site container too. Some attributes under site conta=
iner should belong to vpn-svc per
 site container such as vpn-policy, service, etc. The site container needs =
to have a parameter “multiplexing” to indicate if a site will h=
ave single vpn or multiple vpn. This will address the issue of multi-vpn at=
 a site discussed in today’s interim meeting.


 


Not sure why need site-template container.


 


Regards,


Lucy


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.






--_000_655C07320163294895BBADA28372AF5D486D0D92FR712WXCHMBA15z_--


From nobody Fri Feb 26 09:14:36 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5211B2BB4 for ; Fri, 26 Feb 2016 09:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.304
X-Spam-Level: 
X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 qslUh0CfRxmz for ; Fri, 26 Feb 2016 09:14:28 -0800 (PST)
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 937C71B2BAB for ; Fri, 26 Feb 2016 09:14:27 -0800 (PST)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id E345B40290; Fri, 26 Feb 2016 18:14:25 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id B666A120055; Fri, 26 Feb 2016 18:14:25 +0100 (CET)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0279.002; Fri, 26 Feb 2016 18:14:25 +0100
From: 
To: "Scharf, Michael (Nokia - DE)" , Lucy yong , Aijun Wang <13301168517@189.cn>, "l3sm@ietf.org" 
Thread-Topic: [L3sm] L3 service model suggestion
Thread-Index: AQHRcLCALzWoCubFb0ygwLOyB5frWZ8+deWAgAAac5A=
Date: Fri, 26 Feb 2016 17:14:24 +0000
Message-ID: <29199_1456506865_56D087F1_29199_17735_1_9E32478DFA9976438E7A22F69B08FF92168CF665@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <005001d17034$26bb1460$74313d20$@cn> <28091_1456475302_56D00CA6_28091_2131_1_9E32478DFA9976438E7A22F69B08FF92168CDD59@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D5724619D@dfweml701-chm> <26279_1456501089_56D07161_26279_1306_1_9E32478DFA9976438E7A22F69B08FF92168CF246@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D572461F1@dfweml701-chm> <24712_1456503140_56D07964_24712_11500_1_9E32478DFA9976438E7A22F69B08FF92168CF4AA@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <655C07320163294895BBADA28372AF5D486D0D92@FR712WXCHMBA15.zeu.alcatel-lucent.com>
In-Reply-To: <655C07320163294895BBADA28372AF5D486D0D92@FR712WXCHMBA15.zeu.alcatel-lucent.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: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92168CF665OPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2016 17:14:35 -0000

--_000_9E32478DFA9976438E7A22F69B08FF92168CF665OPEXCLILMA4corp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Michael,

Regarding our customers, I can tell that most of the big accounts are using=
 multiVPN (or even all of them ?), subVPN is less used but there is an inte=
rest also.
MultiVPN is really typical scenario.

Best Regards,

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Friday, February 26, 2016 17:38
To: LITKOWSKI Stephane SCE/OINIS; Lucy yong; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

For what it is worth, I am a bit surprised by this discussion on optimizing=
 the model for the multiVPN use case. I am not really aware of a strong int=
erest in this particular use case, but obviously this depends on usage and =
deployment scenarios.

I'd suggest to keep the model simple for the case of a single VPN. For the =
vanilla L3VPN use case it would be good to avoid having to manipulate multi=
ple lists, maintain cross-references, etc. Maybe this can be achieved my ma=
king all model components only required for multi VPN optional? KISS princi=
ple...

Michael



From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of EXT stephane.litkows=
ki@orange.com
Sent: Friday, February 26, 2016 5:12 PM
To: Lucy yong; Aijun Wang; l3sm@ietf.org; Scharf, Mic=
hael (Nokia - DE)
Subject: Re: [L3sm] L3 service model suggestion

>From a service design point of view, it works for me. But I'm not an implem=
entor, so there may be some implementation constraints/requirement that we =
need also to take care of : so I cannot really go against Michael who provi=
ded an implementation view point.

Michael,

May be can you elaborate on the constraints you see by introducing a list o=
f sites (just references) in the vpn-svc container ? Is it strong or not ?

Thx


From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Friday, February 26, 2016 17:01
To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi Stephane, et al,

I did not understand Michael's previous mail. So just give my opinion. Than=
k you to point out his concern.

IMO: Our goal here is to work out the model that can cover common L3 VPN se=
rvices. If a site attaching to multiple VPNs is a common use case, we need =
to address it. We want to have one service model to cover single VPN and mu=
ltiple VPN at a site too. I don't see that two list entries is a problem to=
 concern here.

Regards,
Lucy



From: stephane.litkowski@orange.com [=
mailto:stephane.litkowski@orange.com]
Sent: Friday, February 26, 2016 9:38 AM
To: Lucy yong; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Yes this works but this was identified by Michael Scharf as an issue, see m=
ail attached


"would require two different list entries to be present before a site can a=
ctually be configured. I would prefer to void such dependencies as far as p=
ossible, in order to simplify the use of the model and avoid internal incon=
sistencies."


From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Friday, February 26, 2016 16:27
To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Share my 2-cent.

A VPN has a list of sites, which can be covered by the attribute of a list =
of site under vpn-svc container. This attribute just contains the site refe=
rence.
L3SM needs a site container to cover site attributes because individual sit=
es have different properties.
L3SM needs a vpn-svc per site container that contains the attributes for a =
vpn-svc relevant to a site, i.e. vpn end point at a site.

Using these three containers, we can model a site that can have either sing=
le VPN or multiple VPNs.

Does this make a sense?

Thanks,
Lucy





From: stephane.litkowski@orange.com [=
mailto:stephane.litkowski@orange.com]
Sent: Friday, February 26, 2016 2:28 AM
To: Aijun Wang; Lucy yong; l3sm@ietf.org
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Again,  in a multiVPN scenario, we have a SINGLE logical site so if you use=
 site under vpn-svc you will have to duplicate all the site information (ro=
uting-protocols, security , ip addressing ...) and it's useless because it =
will be exactly the same. So the model becomes really heavy to use while to=
day it's really flexible.
This duplication is a no GO for me. Now if you go to use a reference to a t=
emplate, it's exactly the same like having a site-list with references only=
 that I proposed, but Michael had a very good argument telling that splitti=
ng the site attributes in two subtree is a very bad idea.

I don't really understand the old argument telling that putting sites under=
 vpn is more service oriented. This is for sure another way to model it, bu=
t the current way is also service oriented but we separate sites and VPN to=
 have the best flexibility in mapping sites to VPNs. Multiple service provi=
ders are using this kind of separation between VPN and sites in their infor=
mation system today (this was one of the first outcomes when we started thi=
s modeling exercice).

Now from an operational point of view (not configuration), people need to e=
asy access the list of sites per VPN, we can create an read-only container =
for that purpose.


From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, February 26, 2016 02:22
To: 'Lucy yong'; l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi, Lucy:

Is it more clear to put the list site within the list vpn-svc? This correla=
te naturally the relationship between vpn id and its associated sites, and =
also the attributes of these sites.
For site that belong to multiple vpn, the site' information will be existed=
 in several specific vpn context. Considering the site's attribute may be v=
ary for different vpn, it is reasonable for the customer.

For site-template container, I propose:
1.  we change it into grouping site-template, and use it within list sites,=
 or
2. define the related items directly  within the list sites and eliminate t=
he site-template container.

Best Regards.

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, February 25, 2016 11:59 PM
To: l3sm@ietf.org
Subject: [L3sm] L3 service model suggestion

Hi All,

Current L3vpn service model (the draft) specifies vpn-svc and site containe=
rs only. In order to address multiple vpn at one site, we need vpn-svc per =
site container too. Some attributes under site container should belong to v=
pn-svc per site container such as vpn-policy, service, etc. The site contai=
ner needs to have a parameter "multiplexing" to indicate if a site will hav=
e single vpn or multiple vpn. This will address the issue of multi-vpn at a=
 site discussed in today's interim meeting.

Not sure why need site-template container.

Regards,
Lucy

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________

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_9E32478DFA9976438E7A22F69B08FF92168CF665OPEXCLILMA4corp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Michael,=



 


Regarding our customer=
s, I can tell that most of the big accounts are using multiVPN (or even all=
 of them ?), subVPN is less used but there is an interest also.<=
/span>


MultiVPN is really typ=
ical scenario.


 


Best Regards,


 






From: Scharf, =
Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]


Sent: Friday, February 26, 2016 17:38

To: LITKOWSKI Stephane SCE/OINIS; Lucy yong; Aijun Wang; l3sm@ietf.o=
rg

Subject: RE: [L3sm] L3 service model suggestion






 


For what it is worth, =
I am a bit surprised by this discussion on optimizing the model for the mul=
tiVPN use case. I am not really aware of a strong interest in this particul=
ar use case, but obviously this depends
 on usage and deployment scenarios. 


 


I’d suggest to k=
eep the model simple for the case of a single VPN. For the vanilla L3VPN us=
e case it would be good to avoid having to manipulate multiple lists, maint=
ain cross-references, etc. Maybe this can
 be achieved my making all model components only required for multi VPN opt=
ional? KISS principle…


 


Michael


 


 


 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of EXT st=
ephane.litkowski@orange.com

Sent: Friday, February 26, 2016 5:12 PM

To: Lucy yong; Aijun Wang; l3sm@iet=
f.org; Scharf, Michael (Nokia - DE)

Subject: Re: [L3sm] L3 service model suggestion






 


From a service design =
point of view, it works for me. But I’m not an implementor, so there =
may be some implementation constraints/requirement that we need also to tak=
e care of : so I cannot really go against
 Michael who provided an implementation view point.


 


Michael,


 


May be can you elabora=
te on the constraints you see by introducing a list of sites (just referenc=
es) in the vpn-svc container ? Is it strong or not ?


 


Thx<=
/p>

 


 






From: Lucy yon=
g [mailto:lucy.yong@huawei.com]


Sent: Friday, February 26, 2016 17:01

To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; 
l3sm@ietf.org

Subject: RE: [L3sm] L3 service model suggestion






 


Hi Stephane, et al,=



 


I did not understan=
d Michael’s previous mail. So just give my opinion. Thank you to poin=
t out his concern.


 


IMO: Our goal here =
is to work out the model that can cover common L3 VPN services. If a site a=
ttaching to multiple VPNs is a common use case, we need to address it. We w=
ant to have one service model to cover
 single VPN and multiple VPN at a site too. I don’t see that two list=
 entries is a problem to concern here.


 


Regards,=



Lucy


 


 


 






From:
stephane.litkowski@orange.=
com [mailto:stephane.l=
itkowski@orange.com]


Sent: Friday, February 26, 2016 9:38 AM

To: Lucy yong; Aijun Wang; l3sm@iet=
f.org

Subject: RE: [L3sm] L3 service model suggestion






 


Yes this works but thi=
s was identified by Michael Scharf as an issue, see mail attached


 


“would=
 require two different list entries to be present before a site can actuall=
y be configured. I would prefer to void such dependencies as far as possibl=
e, in order to simplify the use of the model
 and avoid internal inconsistencies.”


 


 






From: Lucy yon=
g [mailto:lucy.yong@huawei.com]


Sent: Friday, February 26, 2016 16:27

To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; 
l3sm@ietf.org

Subject: RE: [L3sm] L3 service model suggestion






 


Hi,


 


Share my 2-cent.


 


A VPN has a list of=
 sites, which can be covered by the attribute of a list of site under vpn-s=
vc container. This attribute just contains the site reference.


L3SM needs a site c=
ontainer to cover site attributes because individual sites have different p=
roperties.


L3SM needs a vpn-sv=
c per site container that contains the attributes for a vpn-svc relevant to=
 a site, i.e. vpn end point at a site.


 


Using these three c=
ontainers, we can model a site that can have either single VPN or multiple =
VPNs.



 


Does this make a se=
nse?


 


Thanks,<=
/span>


Lucy


 


 


 


 


 






From:
stephane.litkowski@orange.=
com [mailto:stephane.l=
itkowski@orange.com]


Sent: Friday, February 26, 2016 2:28 AM

To: Aijun Wang; Lucy yong; l3sm@iet=
f.org

Subject: RE: [L3sm] L3 service model suggestion






 


Hi,<=
/p>

 


Again,  in a mult=
iVPN scenario, we have a SINGLE logical site so if you use site under vpn-s=
vc you will have to duplicate all the site information (routing-protocols, =
security , ip addressing …) and it’s useless
 because it will be exactly the same. So the model becomes really heavy to =
use while today it’s really flexible.


This duplication is a =
no GO for me. Now if you go to use a reference to a template, it’s ex=
actly the same like having a site-list with references only that I proposed=
, but Michael had a very good argument telling
 that splitting the site attributes in two subtree is a very bad idea.=



 


I don’t really u=
nderstand the old argument telling that putting sites under vpn is more ser=
vice oriented. This is for sure another way to model it, but the current wa=
y is also service oriented but we separate
 sites and VPN to have the best flexibility in mapping sites to VPNs. Multi=
ple service providers are using this kind of separation between VPN and sit=
es in their information system today (this was one of the first outcomes wh=
en we started this modeling exercice).


 


Now from an operationa=
l point of view (not configuration), people need to easy access the list of=
 sites per VPN, we can create an read-only container for that purpose.=



 


 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of Aijun Wang

Sent: Friday, February 26, 2016 02:22

To: 'Lucy yong'; l3sm@ietf.org<=
br>
Subject: [L3sm] L3 service model suggestion






 


Hi, L=
ucy:


=
 


Is it=
 more clear to put the list site within the list vpn-svc? This correlate na=
turally the relationship between vpn id and its associated sites, and also =
the attributes of these sites.


For s=
ite that belong to multiple vpn, the site’ information will be existe=
d in several specific vpn context. Considering the site’s attribute m=
ay be vary for different vpn, it is reasonable for
 the customer.


=
 


For s=
ite-template container, I propose:


1. &n=
bsp;we change it into grouping site-template, and use it within list sites,=
 or


2. de=
fine the related items directly  within the list sites and eliminate t=
he site-template container.


=
 


Best =
Regards.


=
 






From: L3sm [mailto:l3sm-bounces@ietf.org]
On Behalf Of Lucy yong

Sent: Thursday, February 25, 2016 11:59 PM

To: l3sm@ietf.org

Subject: [L3sm] L3 service model suggestion






 


Hi All,


 


Current L3vpn service model (the draft) specifies vp=
n-svc and site containers only. In order to address multiple vpn at one sit=
e, we need vpn-svc per site container too. Some attributes under site conta=
iner should belong to vpn-svc per
 site container such as vpn-policy, service, etc. The site container needs =
to have a parameter “multiplexing” to indicate if a site will h=
ave single vpn or multiple vpn. This will address the issue of multi-vpn at=
 a site discussed in today’s interim meeting.


 


Not sure why need site-template container.


 


Regards,


Lucy


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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


From nobody Fri Feb 26 10:13:00 2016
Return-Path: 
X-Original-To: l3sm@ietf.org
Delivered-To: l3sm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E469F1B2D0B; Fri, 26 Feb 2016 10:05:41 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Liaison Statement Management Tool 
To: , , , , , , , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160226180541.18278.30437.idtracker@ietfa.amsl.com>
Date: Fri, 26 Feb 2016 10:05:41 -0800
Archived-At: 
X-Mailman-Approved-At: Fri, 26 Feb 2016 10:13:00 -0800
Cc: L3VPN Service Model Discussion List , Multiprotocol Label Switching Discussion List , Deborah Brungard , IP Performance Metrics Discussion List , Bill Cerveny , Bill Bjorkman , Benoit Claise , Nan Chen , Alia Atlas , Joel Jaeggli , Martin Stiemerling , The IETF Chair , Spencer Dawkins , Raghu Ranganathan , Adrian Farrel , Ross Callon , Brian Trammell , Alvaro Retana , George Swallow , Qin Wu , Loa Andersson 
Subject: [L3sm] New Liaison Statement, "Liaison from MEF on IP Service Attributes"
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
List-Id: L3VPN Service YANG  Model discussion group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 18:05:42 -0000

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


From nobody Fri Feb 26 12:02:24 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191AD1B2F64 for ; Fri, 26 Feb 2016 12:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102
X-Spam-Level: 
X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
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 sCM4N2swShmG for ; Fri, 26 Feb 2016 12:02:20 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4491B2F69 for ; Fri, 26 Feb 2016 12:02:10 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u1QK28nx004871 for ; Fri, 26 Feb 2016 20:02:08 GMT
Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u1QK27Pj004844 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 26 Feb 2016 20:02:08 GMT
From: "Adrian Farrel" 
To: 
References: <20160226180541.18278.30437.idtracker@ietfa.amsl.com>
In-Reply-To: <20160226180541.18278.30437.idtracker@ietfa.amsl.com>
Date: Fri, 26 Feb 2016 20:02:07 -0000
Message-ID: <01e301d170d0$929a0190$b7ce04b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDut+wpCEdv+aFuSgD94NBIxfmeU6EELnpQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22158.001
X-TM-AS-Result: No--27.583-10.0-31-10
X-imss-scan-details: No--27.583-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtHvkBiM1eNiXlu4M/xm4KZe9mnDjfUPq55kljqvtoNIdjzW aLWbt415dCQVIAR6sWaTz9wa1hxOtEdvGfWAnllX6/xAZojbl7e+8YVU8r+aqC6PLFEfB74c7nP 5+9Z3Og1rrAT5G0XZxPFPDHhQkgxydJXLWwFEzTr7PZziWKg+SFNDrIPosXvFAIZpxx3hp71Btb hSKQOLQiJ6Ql5Qk9DPsfJ5vKZeu+glr4UAbUFME/45MImNrSZy+KgiyLtJrSBUvRK1+R1DYi9TC OyVuKCIL1NpBYi6UhlJHUy0oWekE2hfZ0C50I/bwVaayvK71l/uHZGuwo6K7bl+jVyLzmC7+iVH ADTizbhd8IoL9cNaFlFUtaktOihG3AFJ0Abr1OSjrlYm3WTU74ab/1O/b86B2By6TaLG/FYtUJB 9LGI9xmAO738Oe6NfLNL3mIdAIX42vQUyPTk8IUAvdL4TzpZNoprEeoZHCQIUWf/cATIRrMXRJN gWv23SDD5+MJQYitKoKK25aAKEtf5ZosiHqQrNylAqNTt8FdWNmdPCKLAdu+Q3Q44he/NIT5jNh KqBMgatEJTJS+OyYMgYKUeOkNfS4X8HWMSNX7ozSlmIs9AhOkbbuL7Y47c078UjS8LVUAf2DFj4 3cvg+I0TMEcVjHNwfKcyGJZ2UplL7Dhhh55txth3b7/zBhN1rxZQ031Z6Fpw3ACKo+6ZwlaesTr cFv5b5rWiG+FMYPGdJZY9iykFVOHQff/Y9Ps7bQ9aoPSmWJHNUTeBBPKQKp3BT+pdjEe8kyGMOJ yKxBEVGnmdEWOrGXIsYORvUxxe+zoAW8R15l+eAiCmPx4NwFkMvWAuahr8trNGq+WQEvSrusVRy 4an8bxAi7jPoeEQftwZ3X11IV0=
Archived-At: 
Subject: Re: [L3sm] New Liaison Statement, "Liaison from MEF on IP Service Attributes"
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 26 Feb 2016 20:02:23 -0000

All,

This liaison seems to notify us of work that "is different" from what we =
are doing, but where the authors of this communication believe "there is =
some synergy between the L3SM work and this MEF project."

Following the link supplied and using the username "mef" fails for me as =
a password is required. Let me know if you have any success.

In the man time, I suggest we wait to see whether anyone makes any =
comments on the mailing list with a view to ensuring that the =
"specifications are aligned."

Adrian

> -----Original Message-----
> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]
> Sent: 26 February 2016 18:06
> To: ietf@wjcerveny.com; joelja@bogus.com; bclaise@cisco.com;
> adrian@olddog.co.uk; rcallon@juniper.net; ietf@trammell.ch;
> swallow.ietf@gmail.com; bill.wu@huawei.com; loa@pi.nu
> Cc: rraghu@ciena.com; IP Performance Metrics Discussion List; =
Multiprotocol
> Label Switching Discussion List; Brian Trammell; Nan Chen; Ross =
Callon; L3VPN
> Service Model Discussion List; Spencer Dawkins; George Swallow; Martin
> Stiemerling; Bill Bjorkman; Alia Atlas; The IETF Chair; Joel Jaeggli; =
Adrian Farrel; Qin
> Wu; Bill Cerveny; Deborah Brungard; Raghu Ranganathan; Loa Andersson; =
Benoit
> Claise; Alvaro Retana
> Subject: New Liaison Statement, "Liaison from MEF on IP Service =
Attributes"
>=20
> 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/
>=20
> 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
>=20
> 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.
>=20
> 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).
>=20
> 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").
>=20
> 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 =E2=80=93 each Service Provider must form =
a specific
> bilateral agreement with each other Service Provider they wish to =
connect with.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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:
>=20
>     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


From nobody Fri Feb 26 17:49:31 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C9E1A8AC3 for ; Fri, 26 Feb 2016 17:49:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.156
X-Spam-Level: 
X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 QSstSJ6G0Xcl for ; Fri, 26 Feb 2016 17:49:27 -0800 (PST)
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 0B0E31A8AB3 for ; Fri, 26 Feb 2016 17:49:26 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFB02147; Sat, 27 Feb 2016 01:49:25 +0000 (GMT)
Received: from LHREML706-CAH.china.huawei.com (10.201.5.182) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 27 Feb 2016 01:49:24 +0000
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 27 Feb 2016 01:49:23 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.35]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Sat, 27 Feb 2016 09:49:11 +0800
From: Qin Wu 
To: Lucy yong , "l3sm@ietf.org" 
Thread-Topic: L3 service model suggestion
Thread-Index: AdFv5NXohY58UF8wRLqEAwIfFWnLNAAXBAtAABqAjhAAFReCMA==
Date: Sat, 27 Feb 2016 01:49:10 +0000
Message-ID: 
References: <2691CE0099834E4A9C5044EEC662BB9D57245D3B@dfweml701-chm>  <2691CE0099834E4A9C5044EEC662BB9D572461D5@dfweml701-chm>
In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572461D5@dfweml701-chm>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.78.208]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA852C957Cnkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.56D100A5.004D, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.35, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4fe33dfc2a3f4b5bce056303cf192d08
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 27 Feb 2016 01:49:29 -0000

--_000_B8F9A780D330094D99AF023C5877DABA852C957Cnkgeml513mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SSBiZWxpZXZlIHNlY3Rpb24gNSBjb3ZlcnMgd2hhdCB5b3UgYXJlIGFza2luZyBmb3IgcmVnYXJk
bGVzcyBvZiBzaW5nbGUgVlBOLCBtdWx0aXBsZSBWUE4uIEkgd291bGQgc3VnZ2VzdCB5b3UgbmVl
ZCB0byBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUgbW9kZWwgZGVzaWduIHByaW5jaXBsZSBpbiB0aGUg
Y3VycmVudCBtb2RlbCB3ZSBoYXZlIHdvcmtlZCBmb3IgcXVpdGUgYSBsb25nIHRpbWUgYW5kIGNv
bnN1bHQgd2l0aCBhdXRob3Igb2Ygc2VydmljZSBtb2RlbCBkcmFmdCBpZiB5b3UgaGF2ZSBhbnkg
ZnVydGhlciBxdWVzdGlvbnMuDQpUaGFua3MgZm9yIHlvdXIgaGlnaCBsZXZlbCByZXZpZXcgYW5k
IHlvdXIgcHJvcG9zYWwgb24gobBtdWx0aXBsZXhpbmehsS4gV2hldGhlciB3ZSBuZWVkIGFuIGV4
cGxpY2l0IHBhcmFtZXRlciB0byBkaXN0aW5jdCBzaW5nbGUgdnBuIGZyb20gbXVsdGlwbGUgdnBu
LCBJIGxlYXZlIHRoaXMgdG8gYXV0aG9ycy4gVGhhbmtzIGFnYWluLg0KDQotUWluDQq3orz+yMs6
IEx1Y3kgeW9uZw0Kt6LLzcqxvOQ6IDIwMTbE6jLUwjI2yNUgMjM6NTANCsrVvP7IyzogUWluIFd1
OyBsM3NtQGlldGYub3JnDQrW98ziOiBSRTogTDMgc2VydmljZSBtb2RlbCBzdWdnZXN0aW9uDQoN
CkhpIFFpbiwNCg0KUGxlYXNlIHNlZSBiZWxvdy4NCg0KRnJvbTogUWluIFd1DQpTZW50OiBUaHVy
c2RheSwgRmVicnVhcnkgMjUsIDIwMTYgOToxNSBQTQ0KVG86IEx1Y3kgeW9uZzsgbDNzbUBpZXRm
Lm9yZzxtYWlsdG86bDNzbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBMMyBzZXJ2aWNlIG1vZGVs
IHN1Z2dlc3Rpb24NCg0KSGksIEx1Y3k6DQq3orz+yMs6IEwzc20gW21haWx0bzpsM3NtLWJvdW5j
ZXNAaWV0Zi5vcmddILT6se0gTHVjeSB5b25nDQq3osvNyrG85DogMjAxNsTqMtTCMjXI1SAyMzo1
OQ0KytW8/sjLOiBsM3NtQGlldGYub3JnPG1haWx0bzpsM3NtQGlldGYub3JnPg0K1vfM4jogW0wz
c21dIEwzIHNlcnZpY2UgbW9kZWwgc3VnZ2VzdGlvbg0KDQpIaSBBbGwsDQoNCkN1cnJlbnQgTDN2
cG4gc2VydmljZSBtb2RlbCAodGhlIGRyYWZ0KSBzcGVjaWZpZXMgdnBuLXN2YyBhbmQgc2l0ZSBj
b250YWluZXJzIG9ubHkuIEluIG9yZGVyIHRvIGFkZHJlc3MgbXVsdGlwbGUgdnBuIGF0IG9uZSBz
aXRlLCB3ZSBuZWVkIHZwbi1zdmMgcGVyIHNpdGUgY29udGFpbmVyIHRvby4gU29tZSBhdHRyaWJ1
dGVzIHVuZGVyIHNpdGUgY29udGFpbmVyIHNob3VsZCBiZWxvbmcgdG8gdnBuLXN2YyBwZXIgc2l0
ZSBjb250YWluZXIgc3VjaCBhcyB2cG4tcG9saWN5LCBzZXJ2aWNlLCBldGMuDQoNCltRaW5dOiBJ
IGJlbGlldmUgdnBuLXBvbGljeSBoYXMgYWxyZWFkeSBiZWVuIG1vZGVsZWQgYXMgdnBuLXN2YyBw
ZXIgc2l0ZSwgc2VlIHNlY3Rpb24gNS4yLjINCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1pZXRmLWwzc20tbDN2cG4tc2VydmljZS1tb2RlbC0wMiNzZWN0aW9uLTUuMi4yDQpGb3Ig
c2VydmljZSwgd2hhdCBhcmUgZGVmaW5lZCBmb3Igc2VydmljZSBhcmUgY29tbW9uIGF0dHJpYnV0
ZXMgdGhhdCBhcmUgYXBwbGllZCB0byBhbGwgdGhlIFZQTiBzZXJ2aWNlIGlmIG9uZSBzaXRlIGJl
bG9uZ2luZyB0byBtdWx0aXBsZSBWUE4gc2VydmljZS4NClBsZWFzZSBzZWUgZXhhbXBsZXMgaW4g
dGhlIHNlY3Rpb24gNS4yLjYuDQpbW0x1Y3ldXSBJIHNlZSB0aGUgZGVzY3JpcHRpb24uIEJ1dCB0
aGUgWUFORyBtb2R1bGUgaW4gc2VjdGlvbiA1IGNhbiBub3QgY292ZXIgdGhlIGNhc2UgdGhhdCBh
IHNpdGUgdGhhdCBhdHRhY2hlcyB0byBtdWx0aXBsZSBWUE5zIGFuZCBkaWZmZXJlbnQgc2Vydmlj
ZSBwb2xpY2llcyBmb3IgaW5kaXZpZHVhbCBWUE5zLiBJIHRoaW5rIHRoaXMgaXMgY29tbW9uIHVz
ZSBjYXNlLg0KDQpUaGUgc2l0ZSBjb250YWluZXIgbmVlZHMgdG8gaGF2ZSBhIHBhcmFtZXRlciCh
sG11bHRpcGxleGluZ6GxIHRvIGluZGljYXRlIGlmIGEgc2l0ZSB3aWxsIGhhdmUgc2luZ2xlIHZw
biBvciBtdWx0aXBsZSB2cG4uIFRoaXMgd2lsbCBhZGRyZXNzIHRoZSBpc3N1ZSBvZiBtdWx0aS12
cG4gYXQgYSBzaXRlIGRpc2N1c3NlZCBpbiB0b2RheaGvcyBpbnRlcmltIG1lZXRpbmcuDQoNCltR
aW5dOiBGb3IgdnBuLXBvbGljeSwgaXQgaXMgaW1wbGljaXRseSBpbmRpY2F0ZWQgYnkgdGhlIG51
bWJlciBvZiBwb2xpY3kgZW50cmllcy4NCltbTHVjeV1dIElNTzogd2hldGhlciBzaXRlIGF0dGFj
aGluZyB0byBzaW5nbGUgVlBOIG9yIG11bHRpcGxlIFZQTnMgaXMgYSBtYWpvciBzZXJ2aWNlIHBy
b3BlcnR5LCAgZ29vZCB0byBoYXZlIGFuIGF0dHJpYnV0ZSB0byBkaWZmZXJlbnRpYXRlIHR3byBj
YXNlcy4gVGhpcyBpcyByZWxhdGVkIHRvIHNpdGUgYXR0cmlidXRlLCBub3QgVlBOLXBvbGljeS4N
Cg0KTm90IHN1cmUgd2h5IG5lZWQgc2l0ZS10ZW1wbGF0ZSBjb250YWluZXIuDQoNCltRaW5dOiBT
aXRlLXRlbXBsYXRlcyBhbGxvdyB0byBkZWZpbmUgY29uZmlndXJhdGlvbiBibG9ja3MgdGhhdCB3
aWxsIGJlICBpbmhlcml0ZWQgYnkgb25lIG9yIG11bHRpcGxlIHNpdGVzIGluIG9yZGVyIHRvIHNw
ZWVkIHVwDQogICBjb25maWd1cmF0aW9uLiBTZWUgbW9yZSBkZXRhaWxzIGluIHNlY3Rpb24gNS40
IG9mIHNlcnZpY2UgbW9kZWwgZHJhZnQuDQpbW0x1Y3ldXSBJIHN0aWxsIGRvbqGvdCBrbm93IHRo
ZSB2YWx1ZSBvZiBpdCB5ZXQuIEkgd2lsbCByZWFkIG1vcmUgYW5kIGxlYXJuLiA6KQ0KDQpUaGFu
a3MsDQpMdWN5DQoNClJlZ2FyZHMsDQpMdWN5DQo=

--_000_B8F9A780D330094D99AF023C5877DABA852C957Cnkgeml513mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











I believe section 5 covers what you are asking for regardless of =
single VPN, multiple VPN. I would suggest you need to better understand the=
 model design principle in the current
 model we have worked for quite a long time and consult with author of serv=
ice model draft if you have any further questions.


Thanks for your high level review and your proposal on =A1=B0mult=
iplexing=A1=B1. Whether we need an explicit parameter to distinct single vp=
n from multiple vpn, I leave this to authors. Thanks
 again.


 


-Qin






=B7=A2=BC=FE=C8=CB: Lucy yo=
ng


=B7=A2=
=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C226=C8=D5
 23:50

=CA=D5=BC=FE=C8=CB: Qin Wu; l3sm@ietf.org

=D6=F7=CC=E2: RE: L3 service model suggestion






 


Hi Q=
in,


 


Plea=
se see below.


 






From: Qin Wu


Sent: Thursday, February 25, 2016 9:15 PM

To: Lucy yong; l3sm@ietf.org
Subject: RE: L3 service model suggestion






 


Hi, Lucy:






=B7=A2=BC=FE=C8=CB: L3sm [<=
a href=3D"mailto:l3sm-bounces@ietf.org">mailto:l3sm-bounces@ietf.org]
=B4=FA=
=B1=ED Lucy yong

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C225=C8=D5
 23:59

=CA=D5=BC=FE=C8=CB: 
l3sm@ietf.org

=D6=F7=CC=E2: [L3sm] L3 service model suggestion






 


Hi All,


 


Current L3vpn service model (th=
e draft) specifies vpn-svc and site containers only. In order to address mu=
ltiple vpn at one site, we need vpn-svc per site container too. Some attrib=
utes under site container should belong
 to vpn-svc per site container such as vpn-policy, service, etc. 



 


[Qin]: I believe vpn-policy has already been modeled as vpn-svc p=
er site, see section 5.2.2


https://tools.ietf.org/html/draft-ietf-l3sm-l3v=
pn-service-model-02#section-5.2.2


For service, what are defined for service are common attributes t=
hat are applied to all the VPN service if one site belonging to multiple VP=
N service.


Please see examples in the section 5.2.6.


[=
[Lucy]] I see the description. But the YANG module in section 5 can not cov=
er the case that a site that attaches to multiple VPNs and different servic=
e policies for individual VPNs. I think
 this is common use case. 


 


The site container needs to hav=
e a parameter =A1=B0multiplexing=A1=B1 to indicate if a site will have sing=
le vpn or multiple vpn. This will address the issue of multi-vpn at a site =
discussed in today=A1=AFs interim meeting.


&n=
bsp;


[Qin]: For vpn-policy, it is implicitly indicated by the number o=
f policy entries.


[=
[Lucy]] IMO: whether site attaching to single VPN or multiple VPNs is a maj=
or service property,  good to have an attribute to differentiate two c=
ases. This is related to site attribute, not
 VPN-policy.=



 


Not sure why need site-template=
 container.


&n=
bsp;


[Qin]: Site-templates allow to define configuration blocks that w=
ill be  inherited by one or multiple sites in order to speed up


   configuration. See more details in section 5.4 of se=
rvice model draft.


[=
[Lucy]] I still don=A1=AFt know the value of it yet. I will read more and l=
earn.
J  &n=
bsp;


<=
o:p> 


T=
hanks,


L=
ucy 


 


Regards,


Lucy






--_000_B8F9A780D330094D99AF023C5877DABA852C957Cnkgeml513mbschi_--


From nobody Mon Feb 29 00:29:29 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175FA1B2DED for ; Mon, 29 Feb 2016 00:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.146
X-Spam-Level: *
X-Spam-Status: No, score=1.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 GMBdZRjB0DU4 for ; Mon, 29 Feb 2016 00:29:26 -0800 (PST)
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 9F4D01B2DEB for ; Mon, 29 Feb 2016 00:29:25 -0800 (PST)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id CB533C0223; Mon, 29 Feb 2016 09:29:23 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 8385520066; Mon, 29 Feb 2016 09:29:23 +0100 (CET)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0279.002; Mon, 29 Feb 2016 09:29:23 +0100
From: 
To: Qin Wu , Lucy yong , "l3sm@ietf.org" 
Thread-Topic: L3 service model suggestion
Thread-Index: AdFv5NXohY58UF8wRLqEAwIfFWnLNAAXBAtAABqAjhAAFReCMAByxWeA
Date: Mon, 29 Feb 2016 08:29:22 +0000
Message-ID: <27866_1456734563_56D40163_27866_3093_1_9E32478DFA9976438E7A22F69B08FF92168D58A4@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <2691CE0099834E4A9C5044EEC662BB9D57245D3B@dfweml701-chm>  <2691CE0099834E4A9C5044EEC662BB9D572461D5@dfweml701-chm> 
In-Reply-To: 
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: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92168D58A4OPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Feb 2016 08:29:28 -0000

--_000_9E32478DFA9976438E7A22F69B08FF92168D58A4OPEXCLILMA4corp_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGksDQoNCkkgdGhpbmsgdGhlIKGwbXVsdGlwbGV4aW5nobEga2V5d29yZCBMdWN5IHdhcyBtZW50
aW9uaW5nIGNvdWxkIG1ha2Ugc2Vuc2UgaWYgV0cgZGVjaWRlIHRvIGdvIHdpdGggdGhlIHByb3Bv
c2FsIGRpc2N1c3NlZCBmb3Igc3ViVlBOIGR1cmluZyB0aGUgY2FsbC4NCg0KUmVtaW5kZXIgb2Yg
dGhlIHByb3Bvc2FsIDoNClVzZSBzaXRlLW5ldHdvcmstYWNjZXNzIHRvIGRlZmluZSBhIHN1YlZQ
TiBhdHRhY2htZW50IGFuZCBhZGQgYSChsHN1Yi1zaXRlLWlkobEgbGVhZiBpbiB0aGlzIGNhc2Uu
DQpBIKGwbXVsdGlwbGV4aW5nobEgbGVhZiBhdCBzaXRlIGxldmVsIG1heSBhbGxvdyB0byBlbmZv
cmNlIHRoZSBwcmVzZW5jZSBvZiB0aGUgc3ViLXNpdGUtaWQuDQoNCkV4YW1wbGUgOg0KDQorLS1y
dyBzaXRlDQogICAgICAgICAgICAgICAgKy0tcncgc2l0ZS1pZA0KICAgICAgICAgICAgICAgICst
LXJ3IChhbGwgc2l0ZSBwcm9wZXJ0aWVzKQ0KICAgICAgICAgICAgICAgICstLXJ3IHZwbi1tdWx0
aXBsZXhpbmcgICAgICAgICAgICAgICAgIGlkZW50aXR5cmVmDQogICAgICAgICAgICAgICAgKy0t
cncgc2l0ZS1uZXR3b3JrLWFjY2Vzc2VzIFtzaXRlLW5ldHdvcmstYWNjZXNzLWlkXQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICArLS1ydyBzaXRlLW5ldHdvcmstYWNjZXNzLWlkDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLXJ3IHN1Yi1zaXRlLWlkICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgLT4gdGhpcyB3aWxsIGJlIG1hbmRhdG9yeSBpZiB2cG4tbXVs
dGlwbGV4aW5nIGlkZW50aXR5IGVxdWFscyB0byChsHN1Yi12cG6hsQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICArLS1ydyAoYWxsIHNpdGUtbmV0d29yay1hY2Nlc3MgcHJvcGVydGll
cykNCg0KDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgUWluIFd1DQpTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMjcsIDIwMTYgMDI6NDkNClRv
OiBMdWN5IHlvbmc7IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTDNzbV0gTDMgc2Vydmlj
ZSBtb2RlbCBzdWdnZXN0aW9uDQoNCkkgYmVsaWV2ZSBzZWN0aW9uIDUgY292ZXJzIHdoYXQgeW91
IGFyZSBhc2tpbmcgZm9yIHJlZ2FyZGxlc3Mgb2Ygc2luZ2xlIFZQTiwgbXVsdGlwbGUgVlBOLiBJ
IHdvdWxkIHN1Z2dlc3QgeW91IG5lZWQgdG8gYmV0dGVyIHVuZGVyc3RhbmQgdGhlIG1vZGVsIGRl
c2lnbiBwcmluY2lwbGUgaW4gdGhlIGN1cnJlbnQgbW9kZWwgd2UgaGF2ZSB3b3JrZWQgZm9yIHF1
aXRlIGEgbG9uZyB0aW1lIGFuZCBjb25zdWx0IHdpdGggYXV0aG9yIG9mIHNlcnZpY2UgbW9kZWwg
ZHJhZnQgaWYgeW91IGhhdmUgYW55IGZ1cnRoZXIgcXVlc3Rpb25zLg0KVGhhbmtzIGZvciB5b3Vy
IGhpZ2ggbGV2ZWwgcmV2aWV3IGFuZCB5b3VyIHByb3Bvc2FsIG9uIKGwbXVsdGlwbGV4aW5nobEu
IFdoZXRoZXIgd2UgbmVlZCBhbiBleHBsaWNpdCBwYXJhbWV0ZXIgdG8gZGlzdGluY3Qgc2luZ2xl
IHZwbiBmcm9tIG11bHRpcGxlIHZwbiwgSSBsZWF2ZSB0aGlzIHRvIGF1dGhvcnMuIFRoYW5rcyBh
Z2Fpbi4NCg0KLVFpbg0Kt6K8/sjLOiBMdWN5IHlvbmcNCreiy83KsbzkOiAyMDE2xOoy1MIyNsjV
IDIzOjUwDQrK1bz+yMs6IFFpbiBXdTsgbDNzbUBpZXRmLm9yZzxtYWlsdG86bDNzbUBpZXRmLm9y
Zz4NCtb3zOI6IFJFOiBMMyBzZXJ2aWNlIG1vZGVsIHN1Z2dlc3Rpb24NCg0KSGkgUWluLA0KDQpQ
bGVhc2Ugc2VlIGJlbG93Lg0KDQpGcm9tOiBRaW4gV3UNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFy
eSAyNSwgMjAxNiA5OjE1IFBNDQpUbzogTHVjeSB5b25nOyBsM3NtQGlldGYub3JnPG1haWx0bzps
M3NtQGlldGYub3JnPg0KU3ViamVjdDogUkU6IEwzIHNlcnZpY2UgbW9kZWwgc3VnZ2VzdGlvbg0K
DQpIaSwgTHVjeToNCreivP7IyzogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZ10g
tPqx7SBMdWN5IHlvbmcNCreiy83KsbzkOiAyMDE2xOoy1MIyNcjVIDIzOjU5DQrK1bz+yMs6IGwz
c21AaWV0Zi5vcmc8bWFpbHRvOmwzc21AaWV0Zi5vcmc+DQrW98ziOiBbTDNzbV0gTDMgc2Vydmlj
ZSBtb2RlbCBzdWdnZXN0aW9uDQoNCkhpIEFsbCwNCg0KQ3VycmVudCBMM3ZwbiBzZXJ2aWNlIG1v
ZGVsICh0aGUgZHJhZnQpIHNwZWNpZmllcyB2cG4tc3ZjIGFuZCBzaXRlIGNvbnRhaW5lcnMgb25s
eS4gSW4gb3JkZXIgdG8gYWRkcmVzcyBtdWx0aXBsZSB2cG4gYXQgb25lIHNpdGUsIHdlIG5lZWQg
dnBuLXN2YyBwZXIgc2l0ZSBjb250YWluZXIgdG9vLiBTb21lIGF0dHJpYnV0ZXMgdW5kZXIgc2l0
ZSBjb250YWluZXIgc2hvdWxkIGJlbG9uZyB0byB2cG4tc3ZjIHBlciBzaXRlIGNvbnRhaW5lciBz
dWNoIGFzIHZwbi1wb2xpY3ksIHNlcnZpY2UsIGV0Yy4NCg0KW1Fpbl06IEkgYmVsaWV2ZSB2cG4t
cG9saWN5IGhhcyBhbHJlYWR5IGJlZW4gbW9kZWxlZCBhcyB2cG4tc3ZjIHBlciBzaXRlLCBzZWUg
c2VjdGlvbiA1LjIuMg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbDNz
bS1sM3Zwbi1zZXJ2aWNlLW1vZGVsLTAyI3NlY3Rpb24tNS4yLjINCkZvciBzZXJ2aWNlLCB3aGF0
IGFyZSBkZWZpbmVkIGZvciBzZXJ2aWNlIGFyZSBjb21tb24gYXR0cmlidXRlcyB0aGF0IGFyZSBh
cHBsaWVkIHRvIGFsbCB0aGUgVlBOIHNlcnZpY2UgaWYgb25lIHNpdGUgYmVsb25naW5nIHRvIG11
bHRpcGxlIFZQTiBzZXJ2aWNlLg0KUGxlYXNlIHNlZSBleGFtcGxlcyBpbiB0aGUgc2VjdGlvbiA1
LjIuNi4NCltbTHVjeV1dIEkgc2VlIHRoZSBkZXNjcmlwdGlvbi4gQnV0IHRoZSBZQU5HIG1vZHVs
ZSBpbiBzZWN0aW9uIDUgY2FuIG5vdCBjb3ZlciB0aGUgY2FzZSB0aGF0IGEgc2l0ZSB0aGF0IGF0
dGFjaGVzIHRvIG11bHRpcGxlIFZQTnMgYW5kIGRpZmZlcmVudCBzZXJ2aWNlIHBvbGljaWVzIGZv
ciBpbmRpdmlkdWFsIFZQTnMuIEkgdGhpbmsgdGhpcyBpcyBjb21tb24gdXNlIGNhc2UuDQoNClRo
ZSBzaXRlIGNvbnRhaW5lciBuZWVkcyB0byBoYXZlIGEgcGFyYW1ldGVyIKGwbXVsdGlwbGV4aW5n
obEgdG8gaW5kaWNhdGUgaWYgYSBzaXRlIHdpbGwgaGF2ZSBzaW5nbGUgdnBuIG9yIG11bHRpcGxl
IHZwbi4gVGhpcyB3aWxsIGFkZHJlc3MgdGhlIGlzc3VlIG9mIG11bHRpLXZwbiBhdCBhIHNpdGUg
ZGlzY3Vzc2VkIGluIHRvZGF5oa9zIGludGVyaW0gbWVldGluZy4NCg0KW1Fpbl06IEZvciB2cG4t
cG9saWN5LCBpdCBpcyBpbXBsaWNpdGx5IGluZGljYXRlZCBieSB0aGUgbnVtYmVyIG9mIHBvbGlj
eSBlbnRyaWVzLg0KW1tMdWN5XV0gSU1POiB3aGV0aGVyIHNpdGUgYXR0YWNoaW5nIHRvIHNpbmds
ZSBWUE4gb3IgbXVsdGlwbGUgVlBOcyBpcyBhIG1ham9yIHNlcnZpY2UgcHJvcGVydHksICBnb29k
IHRvIGhhdmUgYW4gYXR0cmlidXRlIHRvIGRpZmZlcmVudGlhdGUgdHdvIGNhc2VzLiBUaGlzIGlz
IHJlbGF0ZWQgdG8gc2l0ZSBhdHRyaWJ1dGUsIG5vdCBWUE4tcG9saWN5Lg0KDQpOb3Qgc3VyZSB3
aHkgbmVlZCBzaXRlLXRlbXBsYXRlIGNvbnRhaW5lci4NCg0KW1Fpbl06IFNpdGUtdGVtcGxhdGVz
IGFsbG93IHRvIGRlZmluZSBjb25maWd1cmF0aW9uIGJsb2NrcyB0aGF0IHdpbGwgYmUgIGluaGVy
aXRlZCBieSBvbmUgb3IgbXVsdGlwbGUgc2l0ZXMgaW4gb3JkZXIgdG8gc3BlZWQgdXANCiAgIGNv
bmZpZ3VyYXRpb24uIFNlZSBtb3JlIGRldGFpbHMgaW4gc2VjdGlvbiA1LjQgb2Ygc2VydmljZSBt
b2RlbCBkcmFmdC4NCltbTHVjeV1dIEkgc3RpbGwgZG9uoa90IGtub3cgdGhlIHZhbHVlIG9mIGl0
IHlldC4gSSB3aWxsIHJlYWQgbW9yZSBhbmQgbGVhcm4uIDopDQoNClRoYW5rcywNCkx1Y3kNCg0K
UmVnYXJkcywNCkx1Y3kNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl
cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHBy
aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl
cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh
Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUg
ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0
cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUg
dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg
b3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5
IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg
YmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk
IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo
aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo
aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs
IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll
ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg==

--_000_9E32478DFA9976438E7A22F69B08FF92168D58A4OPEXCLILMA4corp_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi,<=
/p>

 


I think the =A1=B0mult=
iplexing=A1=B1 keyword Lucy was mentioning could make sense if WG decide to=
 go with the proposal discussed for subVPN during the call.


 


Reminder of the propos=
al :


Use site-network-acces=
s to define a subVPN attachment and add a =A1=B0sub-site-id=A1=B1 leaf in t=
his case.


A =A1=B0multiplexing=
=A1=B1 leaf at site level may allow to enforce the presence of the sub-site=
-id.


 


Example :


 


+--rw site


   &nbs=
p;            +-=
-rw site-id


   &nbs=
p;            +-=
-rw (all site properties)


   &nbs=
p;            +-=
-rw vpn-multiplexing         &=
nbsp;       identityref


   &nbs=
p;            +-=
-rw site-network-accesses [site-network-access-id]


   &nbs=
p;            &=
nbsp;           &nbs=
p;   +--rw site-network-access-id


   &nbs=
p;            &=
nbsp;           &nbs=
p;   +--rw sub-site-id      &nb=
sp;            =
           -> this wil=
l be mandatory if vpn-multiplexing identity equals to =A1=B0sub-vpn=A1=B1


   &nbs=
p;            &=
nbsp;           &nbs=
p;   +--rw (all site-network-access properties)


 


 






From: L3sm [ma=
ilto:l3sm-bounces@ietf.org]
On Behalf Of Qin Wu

Sent: Saturday, February 27, 2016 02:49

To: Lucy yong; l3sm@ietf.org

Subject: Re: [L3sm] L3 service model suggestion






 


I bel=
ieve section 5 covers what you are asking for regardless of single VPN, mul=
tiple VPN. I would suggest you need to better understand the model design p=
rinciple in the current model we have
 worked for quite a long time and consult with author of service model draf=
t if you have any further questions.


Thank=
s for your high level review and your proposal on =A1=B0multiplexing=A1=B1.=
 Whether we need an explicit parameter to distinct single vpn from multiple=
 vpn, I leave this to authors. Thanks again.


=
 


-Qin<=
o:p>






=B7=A2=BC=FE=C8=CB: Lucy yong


=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C226=C8=D5 23:50

=CA=D5=BC=FE=C8=CB: Qin Wu; l3sm@ietf.org

=D6=F7=CC=E2: RE: L3 service model sugge=
stion






 


Hi Qin,<=
/span>


 


Please see below.


 






From: Qin Wu


Sent: Thursday, February 25, 2016 9:15 PM

To: Lucy yong; l3sm@ietf.org

Subject: RE: L3 service model suggestion






 


Hi, L=
ucy:






=B7=A2=BC=FE=C8=CB: L3sm [mailto:l3sm=
-bounces@ietf.org]
=B4=FA=B1=ED Lucy yong

=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C225=C8=D5 23:59

=CA=D5=BC=FE=C8=CB: l3sm@ietf.org

=D6=F7=CC=E2: [L3sm] L3 service model su=
ggestion






 


Hi All,


 


Current L3vpn service model (the draft) specifies vp=
n-svc and site containers only. In order to address multiple vpn at one sit=
e, we need vpn-svc per site container too. Some attributes under site conta=
iner should belong to vpn-svc per
 site container such as vpn-policy, service, etc. 


=
 


[Qin]=
: I believe vpn-policy has already been modeled as vpn-svc per site, see se=
ction 5.2.2


https://tools.ietf.org/html/draft-ietf-l3sm-l3vpn-service-mode=
l-02#section-5.2.2


For s=
ervice, what are defined for service are common attributes that are applied=
 to all the VPN service if one site belonging to multiple VPN service.=



Pleas=
e see examples in the section 5.2.6.


[[Lucy]] I see t=
he description. But the YANG module in section 5 can not cover the case tha=
t a site that attaches to multiple VPNs and different service policies for =
individual VPNs. I think this is common
 use case. 


=
 


The site container needs to have a parameter =A1=B0m=
ultiplexing=A1=B1 to indicate if a site will have single vpn or multiple vp=
n. This will address the issue of multi-vpn at a site discussed in today=A1=
=AFs interim meeting.


 


[Qin]=
: For vpn-policy, it is implicitly indicated by the number of policy entrie=
s.


[[Lucy]] IMO: wh=
ether site attaching to single VPN or multiple VPNs is a major service prop=
erty,  good to have an attribute to differentiate two cases. This is r=
elated to site attribute, not VPN-policy.


=
 


Not sure why need site-template container.


 


[Qin]=
: Site-templates allow to define configuration blocks that will be  in=
herited by one or multiple sites in order to speed up


 =
;  configuration. See more details in section 5.4 of service model dra=
ft.


[[Lucy]] I still=
 don=A1=AFt know the value of it yet. I will read more and learn.
J<=
/span>   =



 


Thanks,


Lucy =



=
 


Regards,


Lucy




______________________________________________________________________=
___________________________________________________

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


From nobody Mon Feb 29 01:20:35 2016
Return-Path: 
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EB11B2E96 for ; Mon, 29 Feb 2016 01:20:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.156
X-Spam-Level: 
X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 rFy3LnSqKYcP for ; Mon, 29 Feb 2016 01:20:30 -0800 (PST)
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 CABD71B2E98 for ; Mon, 29 Feb 2016 01:20:29 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJH67758; Mon, 29 Feb 2016 09:20:26 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 29 Feb 2016 09:20:24 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.35]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 29 Feb 2016 17:20:12 +0800
From: Qin Wu 
To: "stephane.litkowski@orange.com" , Lucy yong , "l3sm@ietf.org" 
Thread-Topic: L3 service model suggestion
Thread-Index: AdFv5NXohY58UF8wRLqEAwIfFWnLNAAXBAtAABqAjhAAFReCMAByxWeAAAGtQ8A=
Date: Mon, 29 Feb 2016 09:20:12 +0000
Message-ID: 
References: <2691CE0099834E4A9C5044EEC662BB9D57245D3B@dfweml701-chm>  <2691CE0099834E4A9C5044EEC662BB9D572461D5@dfweml701-chm>  <27866_1456734563_56D40163_27866_3093_1_9E32478DFA9976438E7A22F69B08FF92168D58A4@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <27866_1456734563_56D40163_27866_3093_1_9E32478DFA9976438E7A22F69B08FF92168D58A4@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.78.208]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA852C9EF1nkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56D40D5B.017C, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.35, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6955d8bc56b3bface32c4f3b618da465
Archived-At: 
Subject: Re: [L3sm] L3 service model suggestion
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Feb 2016 09:20:34 -0000

--_000_B8F9A780D330094D99AF023C5877DABA852C9EF1nkgeml513mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

R29vZCwgd2UgaGF2ZW6hr3QgZ290IHN1YlZQTiBpc3N1ZSBjb25jbHVkZWQgZHVlIHRvIHJ1bm5p
bmcgb3V0IG9mIHRpbWUgaW4gdGhlIGxhc3Qgd2VlayBpbnRlcmltIG1lZXRpbmcuIFRoYW5rIGZv
ciBTdGVwaGFuZaGvcyBwcm9wb3NhbCBvbiBib3RoIHN1YlZQTiBhbmQgbXVsdGlwbGV4aW5nLg0K
SXQgd291bGQgYmUgZ3JlYXQgdG8gc2VlIGEgc2luZ2xlIHByb3Bvc2FsIHRvIGFkZHJlc3Mgc3Vi
VlBOIHRvZ2V0aGVyIHdpdGggobBtdWx0aXBsZXhpbmehsS4NCg0KV0csIHBsZWFzZSBoZWxwIHJl
dmlldyB0aGUgZm9sbG93aW5nIHByb3Bvc2VkIGNoYW5nZSB0byB0aGUgYmFzZSBzZXJ2aWNlIG1v
ZGVsIGFuZCBwcm92aWRlIHlvdXIgb3BpbmlvbiBvbiBpdC4NClRoYW5rcyENCg0KLVFpbg0Kt6K8
/sjLOiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSBbbWFpbHRvOnN0ZXBoYW5lLmxpdGtv
d3NraUBvcmFuZ2UuY29tXQ0Kt6LLzcqxvOQ6IDIwMTbE6jLUwjI5yNUgMTY6MjkNCsrVvP7Iyzog
UWluIFd1OyBMdWN5IHlvbmc7IGwzc21AaWV0Zi5vcmcNCtb3zOI6IFJFOiBMMyBzZXJ2aWNlIG1v
ZGVsIHN1Z2dlc3Rpb24NCg0KSGksDQoNCkkgdGhpbmsgdGhlIKGwbXVsdGlwbGV4aW5nobEga2V5
d29yZCBMdWN5IHdhcyBtZW50aW9uaW5nIGNvdWxkIG1ha2Ugc2Vuc2UgaWYgV0cgZGVjaWRlIHRv
IGdvIHdpdGggdGhlIHByb3Bvc2FsIGRpc2N1c3NlZCBmb3Igc3ViVlBOIGR1cmluZyB0aGUgY2Fs
bC4NCg0KUmVtaW5kZXIgb2YgdGhlIHByb3Bvc2FsIDoNClVzZSBzaXRlLW5ldHdvcmstYWNjZXNz
IHRvIGRlZmluZSBhIHN1YlZQTiBhdHRhY2htZW50IGFuZCBhZGQgYSChsHN1Yi1zaXRlLWlkobEg
bGVhZiBpbiB0aGlzIGNhc2UuDQpBIKGwbXVsdGlwbGV4aW5nobEgbGVhZiBhdCBzaXRlIGxldmVs
IG1heSBhbGxvdyB0byBlbmZvcmNlIHRoZSBwcmVzZW5jZSBvZiB0aGUgc3ViLXNpdGUtaWQuDQoN
CkV4YW1wbGUgOg0KDQorLS1ydyBzaXRlDQogICAgICAgICAgICAgICAgKy0tcncgc2l0ZS1pZA0K
ICAgICAgICAgICAgICAgICstLXJ3IChhbGwgc2l0ZSBwcm9wZXJ0aWVzKQ0KICAgICAgICAgICAg
ICAgICstLXJ3IHZwbi1tdWx0aXBsZXhpbmcgICAgICAgICAgICAgICAgIGlkZW50aXR5cmVmDQog
ICAgICAgICAgICAgICAgKy0tcncgc2l0ZS1uZXR3b3JrLWFjY2Vzc2VzIFtzaXRlLW5ldHdvcmst
YWNjZXNzLWlkXQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS1ydyBzaXRlLW5l
dHdvcmstYWNjZXNzLWlkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLXJ3IHN1
Yi1zaXRlLWlkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLT4gdGhpcyB3aWxsIGJlIG1h
bmRhdG9yeSBpZiB2cG4tbXVsdGlwbGV4aW5nIGlkZW50aXR5IGVxdWFscyB0byChsHN1Yi12cG6h
sQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS1ydyAoYWxsIHNpdGUtbmV0d29y
ay1hY2Nlc3MgcHJvcGVydGllcykNCg0KDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUWluIFd1DQpTZW50OiBTYXR1cmRheSwgRmVicnVhcnkg
MjcsIDIwMTYgMDI6NDkNClRvOiBMdWN5IHlvbmc7IGwzc21AaWV0Zi5vcmc8bWFpbHRvOmwzc21A
aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0wzc21dIEwzIHNlcnZpY2UgbW9kZWwgc3VnZ2VzdGlv
bg0KDQpJIGJlbGlldmUgc2VjdGlvbiA1IGNvdmVycyB3aGF0IHlvdSBhcmUgYXNraW5nIGZvciBy
ZWdhcmRsZXNzIG9mIHNpbmdsZSBWUE4sIG11bHRpcGxlIFZQTi4gSSB3b3VsZCBzdWdnZXN0IHlv
dSBuZWVkIHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSBtb2RlbCBkZXNpZ24gcHJpbmNpcGxlIGlu
IHRoZSBjdXJyZW50IG1vZGVsIHdlIGhhdmUgd29ya2VkIGZvciBxdWl0ZSBhIGxvbmcgdGltZSBh
bmQgY29uc3VsdCB3aXRoIGF1dGhvciBvZiBzZXJ2aWNlIG1vZGVsIGRyYWZ0IGlmIHlvdSBoYXZl
IGFueSBmdXJ0aGVyIHF1ZXN0aW9ucy4NClRoYW5rcyBmb3IgeW91ciBoaWdoIGxldmVsIHJldmll
dyBhbmQgeW91ciBwcm9wb3NhbCBvbiChsG11bHRpcGxleGluZ6GxLiBXaGV0aGVyIHdlIG5lZWQg
YW4gZXhwbGljaXQgcGFyYW1ldGVyIHRvIGRpc3RpbmN0IHNpbmdsZSB2cG4gZnJvbSBtdWx0aXBs
ZSB2cG4sIEkgbGVhdmUgdGhpcyB0byBhdXRob3JzLiBUaGFua3MgYWdhaW4uDQoNCi1RaW4NCrei
vP7IyzogTHVjeSB5b25nDQq3osvNyrG85DogMjAxNsTqMtTCMjbI1SAyMzo1MA0KytW8/sjLOiBR
aW4gV3U7IGwzc21AaWV0Zi5vcmc8bWFpbHRvOmwzc21AaWV0Zi5vcmc+DQrW98ziOiBSRTogTDMg
c2VydmljZSBtb2RlbCBzdWdnZXN0aW9uDQoNCkhpIFFpbiwNCg0KUGxlYXNlIHNlZSBiZWxvdy4N
Cg0KRnJvbTogUWluIFd1DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjUsIDIwMTYgOToxNSBQ
TQ0KVG86IEx1Y3kgeW9uZzsgbDNzbUBpZXRmLm9yZzxtYWlsdG86bDNzbUBpZXRmLm9yZz4NClN1
YmplY3Q6IFJFOiBMMyBzZXJ2aWNlIG1vZGVsIHN1Z2dlc3Rpb24NCg0KSGksIEx1Y3k6DQq3orz+
yMs6IEwzc20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTHVjeSB5b25nDQq3
osvNyrG85DogMjAxNsTqMtTCMjXI1SAyMzo1OQ0KytW8/sjLOiBsM3NtQGlldGYub3JnPG1haWx0
bzpsM3NtQGlldGYub3JnPg0K1vfM4jogW0wzc21dIEwzIHNlcnZpY2UgbW9kZWwgc3VnZ2VzdGlv
bg0KDQpIaSBBbGwsDQoNCkN1cnJlbnQgTDN2cG4gc2VydmljZSBtb2RlbCAodGhlIGRyYWZ0KSBz
cGVjaWZpZXMgdnBuLXN2YyBhbmQgc2l0ZSBjb250YWluZXJzIG9ubHkuIEluIG9yZGVyIHRvIGFk
ZHJlc3MgbXVsdGlwbGUgdnBuIGF0IG9uZSBzaXRlLCB3ZSBuZWVkIHZwbi1zdmMgcGVyIHNpdGUg
Y29udGFpbmVyIHRvby4gU29tZSBhdHRyaWJ1dGVzIHVuZGVyIHNpdGUgY29udGFpbmVyIHNob3Vs
ZCBiZWxvbmcgdG8gdnBuLXN2YyBwZXIgc2l0ZSBjb250YWluZXIgc3VjaCBhcyB2cG4tcG9saWN5
LCBzZXJ2aWNlLCBldGMuDQoNCltRaW5dOiBJIGJlbGlldmUgdnBuLXBvbGljeSBoYXMgYWxyZWFk
eSBiZWVuIG1vZGVsZWQgYXMgdnBuLXN2YyBwZXIgc2l0ZSwgc2VlIHNlY3Rpb24gNS4yLjINCmh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWwzc20tbDN2cG4tc2VydmljZS1t
b2RlbC0wMiNzZWN0aW9uLTUuMi4yDQpGb3Igc2VydmljZSwgd2hhdCBhcmUgZGVmaW5lZCBmb3Ig
c2VydmljZSBhcmUgY29tbW9uIGF0dHJpYnV0ZXMgdGhhdCBhcmUgYXBwbGllZCB0byBhbGwgdGhl
IFZQTiBzZXJ2aWNlIGlmIG9uZSBzaXRlIGJlbG9uZ2luZyB0byBtdWx0aXBsZSBWUE4gc2Vydmlj
ZS4NClBsZWFzZSBzZWUgZXhhbXBsZXMgaW4gdGhlIHNlY3Rpb24gNS4yLjYuDQpbW0x1Y3ldXSBJ
IHNlZSB0aGUgZGVzY3JpcHRpb24uIEJ1dCB0aGUgWUFORyBtb2R1bGUgaW4gc2VjdGlvbiA1IGNh
biBub3QgY292ZXIgdGhlIGNhc2UgdGhhdCBhIHNpdGUgdGhhdCBhdHRhY2hlcyB0byBtdWx0aXBs
ZSBWUE5zIGFuZCBkaWZmZXJlbnQgc2VydmljZSBwb2xpY2llcyBmb3IgaW5kaXZpZHVhbCBWUE5z
LiBJIHRoaW5rIHRoaXMgaXMgY29tbW9uIHVzZSBjYXNlLg0KDQpUaGUgc2l0ZSBjb250YWluZXIg
bmVlZHMgdG8gaGF2ZSBhIHBhcmFtZXRlciChsG11bHRpcGxleGluZ6GxIHRvIGluZGljYXRlIGlm
IGEgc2l0ZSB3aWxsIGhhdmUgc2luZ2xlIHZwbiBvciBtdWx0aXBsZSB2cG4uIFRoaXMgd2lsbCBh
ZGRyZXNzIHRoZSBpc3N1ZSBvZiBtdWx0aS12cG4gYXQgYSBzaXRlIGRpc2N1c3NlZCBpbiB0b2Rh
eaGvcyBpbnRlcmltIG1lZXRpbmcuDQoNCltRaW5dOiBGb3IgdnBuLXBvbGljeSwgaXQgaXMgaW1w
bGljaXRseSBpbmRpY2F0ZWQgYnkgdGhlIG51bWJlciBvZiBwb2xpY3kgZW50cmllcy4NCltbTHVj
eV1dIElNTzogd2hldGhlciBzaXRlIGF0dGFjaGluZyB0byBzaW5nbGUgVlBOIG9yIG11bHRpcGxl
IFZQTnMgaXMgYSBtYWpvciBzZXJ2aWNlIHByb3BlcnR5LCAgZ29vZCB0byBoYXZlIGFuIGF0dHJp
YnV0ZSB0byBkaWZmZXJlbnRpYXRlIHR3byBjYXNlcy4gVGhpcyBpcyByZWxhdGVkIHRvIHNpdGUg
YXR0cmlidXRlLCBub3QgVlBOLXBvbGljeS4NCg0KTm90IHN1cmUgd2h5IG5lZWQgc2l0ZS10ZW1w
bGF0ZSBjb250YWluZXIuDQoNCltRaW5dOiBTaXRlLXRlbXBsYXRlcyBhbGxvdyB0byBkZWZpbmUg
Y29uZmlndXJhdGlvbiBibG9ja3MgdGhhdCB3aWxsIGJlICBpbmhlcml0ZWQgYnkgb25lIG9yIG11
bHRpcGxlIHNpdGVzIGluIG9yZGVyIHRvIHNwZWVkIHVwDQogICBjb25maWd1cmF0aW9uLiBTZWUg
bW9yZSBkZXRhaWxzIGluIHNlY3Rpb24gNS40IG9mIHNlcnZpY2UgbW9kZWwgZHJhZnQuDQpbW0x1
Y3ldXSBJIHN0aWxsIGRvbqGvdCBrbm93IHRoZSB2YWx1ZSBvZiBpdCB5ZXQuIEkgd2lsbCByZWFk
IG1vcmUgYW5kIGxlYXJuLiA6KQ0KDQpUaGFua3MsDQpMdWN5DQoNClJlZ2FyZHMsDQpMdWN5DQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg
Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz
IGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv
cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg
ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy
dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p
cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0
b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv
dSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50
cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0
IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0
ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUg
cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu
ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBt
YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2
ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0K

--_000_B8F9A780D330094D99AF023C5877DABA852C9EF1nkgeml513mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Good, we haven=A1=AFt got subVPN issue concluded due to running o=
ut of time in the last week interim meeting. Thank for Stephane=A1=AFs prop=
osal on both subVPN and multiplexing.



It would be great to see a single proposal to address subVPN toge=
ther with =A1=B0multiplexing=A1=B1.


 


WG, please help review the following proposed change to the base =
service model and provide your opinion on it.



Thanks!


 


-Qin







=B7=A2=BC=FE=C8=CB: stephan=
e.litkowski@orange.com [mailto:stephane.litkowski@orange.com]


=B7=A2=
=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C229=C8=D5
 16:29

=CA=D5=BC=FE=C8=CB: Qin Wu; Lucy yong; l3sm@ietf.org

=D6=F7=CC=E2: RE: L3 service model suggestion






 


Hi,


&n=
bsp;


I think=
 the =A1=B0multiplexing=A1=B1 keyword Lucy was mentioning could make sense =
if WG decide to go with the proposal discussed for subVPN during the call.<=
o:p>


&n=
bsp;


Reminde=
r of the proposal :


Use sit=
e-network-access to define a subVPN attachment and add a =A1=B0sub-site-id=
=A1=B1 leaf in this case.


A =A1=
=B0multiplexing=A1=B1 leaf at site level may allow to enforce the presence =
of the sub-site-id.


&n=
bsp;


Example=
 :


&n=
bsp;


+--=
rw site


 &=
nbsp;           &nbs=
p;  +--rw site-id


 &=
nbsp;           &nbs=
p;  +--rw (all site properties)


 &=
nbsp;           &nbs=
p;  +--rw vpn-multiplexing      &nbs=
p;          identityref


 &=
nbsp;           &nbs=
p;  +--rw site-network-accesses [site-network-access-id]


 &=
nbsp;           &nbs=
p;            &=
nbsp;     +--rw site-network-access-id


 &=
nbsp;           &nbs=
p;            &=
nbsp;     +--rw sub-site-id    =
            &nb=
sp;            =
 -> this will be mandatory if vpn-multiplexing identity equals to =A1=B0=
sub-vpn=A1=B1


 &=
nbsp;           &nbs=
p;            &=
nbsp;     +--rw (all site-network-access properties=
)


&n=
bsp;


&n=
bsp;






From: L3sm [mailto=
:l3sm-bounces@ietf.org]
On Behalf Of Qin Wu

Sent: Saturday, February 27, 2016 02:49

To: Lucy yong; l3sm@ietf.org
Subject: Re: [L3sm] L3 service model suggestion





 


I believe section 5 covers what you are asking for regardless of =
single VPN, multiple VPN. I would suggest you need to better understand the=
 model design principle in the current
 model we have worked for quite a long time and consult with author of serv=
ice model draft if you have any further questions.


Thanks for your high level review and your proposal on =A1=B0mult=
iplexing=A1=B1. Whether we need an explicit parameter to distinct single vp=
n from multiple vpn, I leave this to authors. Thanks
 again.


 


-Qin






=B7=A2=BC=FE=C8=CB: Lucy yo=
ng


=B7=A2=
=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C226=C8=D5
 23:50

=CA=D5=BC=FE=C8=CB: Qin Wu; 
l3sm@ietf.org

=D6=F7=CC=E2: RE: L3 service model suggestion






 


Hi Q=
in,


 


Plea=
se see below.


 






From: Qin Wu


Sent: Thursday, February 25, 2016 9:15 PM

To: Lucy yong; l3sm@ietf.org
Subject: RE: L3 service model suggestion






 


Hi, Lucy:






=B7=A2=BC=FE=C8=CB: L3sm [<=
a href=3D"mailto:l3sm-bounces@ietf.org">mailto:l3sm-bounces@ietf.org]
=B4=FA=
=B1=ED Lucy yong

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2016=C4=EA2=D4=C225=C8=D5
 23:59

=CA=D5=BC=FE=C8=CB: 
l3sm@ietf.org

=D6=F7=CC=E2: [L3sm] L3 service model suggestion






 


Hi All,


 


Current L3vpn service model (th=
e draft) specifies vpn-svc and site containers only. In order to address mu=
ltiple vpn at one site, we need vpn-svc per site container too. Some attrib=
utes under site container should belong
 to vpn-svc per site container such as vpn-policy, service, etc. 



 


[Qin]: I believe vpn-policy has already been modeled as vpn-svc p=
er site, see section 5.2.2


https://tools.ietf.org/html/draft-ietf-l3sm-l3v=
pn-service-model-02#section-5.2.2


For service, what are defined for service are common attributes t=
hat are applied to all the VPN service if one site belonging to multiple VP=
N service.


Please see examples in the section 5.2.6.


[=
[Lucy]] I see the description. But the YANG module in section 5 can not cov=
er the case that a site that attaches to multiple VPNs and different servic=
e policies for individual VPNs. I think
 this is common use case. 


 


The site container needs to hav=
e a parameter =A1=B0multiplexing=A1=B1 to indicate if a site will have sing=
le vpn or multiple vpn. This will address the issue of multi-vpn at a site =
discussed in today=A1=AFs interim meeting.


&n=
bsp;


[Qin]: For vpn-policy, it is implicitly indicated by the number o=
f policy entries.


[=
[Lucy]] IMO: whether site attaching to single VPN or multiple VPNs is a maj=
or service property,  good to have an attribute to differentiate two c=
ases. This is related to site attribute, not
 VPN-policy.=



 


Not sure why need site-template=
 container.


&n=
bsp;


[Qin]: Site-templates allow to define configuration blocks that w=
ill be  inherited by one or multiple sites in order to speed up


   configuration. See more details in section 5.4 of se=
rvice model draft.


[=
[Lucy]] I still don=A1=AFt know the value of it yet. I will read more and l=
earn.
J  &n=
bsp;


<=
o:p> 


T=
hanks,


L=
ucy 


 


Regards,


Lucy


_________________________________________________=
________________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=



they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.=



Thank you.






--_000_B8F9A780D330094D99AF023C5877DABA852C9EF1nkgeml513mbschi_--