From nobody Mon Jan 8 00:36:27 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DCF126D0C for ; Sun, 7 Jan 2018 23:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aricent.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUEj0bbbFWCg for ; Sun, 7 Jan 2018 23:31:41 -0800 (PST) Received: from IND01-MA1-obe.outbound.protection.outlook.com (mail-ma1ind01on0059.outbound.protection.outlook.com [104.47.100.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2955B126B71 for ; Sun, 7 Jan 2018 23:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aricent.onmicrosoft.com; s=selector1-Aricent-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=t0N1f+4PXoxbJ+s+CuVNwIXRWAnFl7SjgPyKN7dcC3E=; b=jt5LsWE2ribzOooxmpUXXgkeHJ2afDEhWe6usInPk+PU0mGEIoN/XDKxp6DOlZTF2fbkXrDJBrAU+jDgPaOmv6LahDxTfI3ck8mocmQYiftiFuvJcCHj2TfW1nJYQIkNYI4XTW6xl40j7rV3odqPNQJ1TQGWZc72G/ADgNpyKbY= Received: from MA1PR0101MB1783.INDPRD01.PROD.OUTLOOK.COM (52.134.142.136) by MA1PR0101MB1784.INDPRD01.PROD.OUTLOOK.COM (52.134.142.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Mon, 8 Jan 2018 07:31:32 +0000 Received: from MA1PR0101MB1783.INDPRD01.PROD.OUTLOOK.COM ([fe80::5d4e:7d85:b261:6fa9]) by MA1PR0101MB1783.INDPRD01.PROD.OUTLOOK.COM ([fe80::5d4e:7d85:b261:6fa9%17]) with mapi id 15.20.0386.009; Mon, 8 Jan 2018 07:31:31 +0000 From: Ashish Mittal To: "l2sm@ietf.org" Thread-Topic: draft-ietf-l2sm-l2vpn-service-model Thread-Index: AdOH2ICD0tS0BEZ3QgSRIb7fcpsU9QAegqEw Date: Mon, 8 Jan 2018 07:31:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ashish.Mittal@aricent.com; x-originating-ip: [61.247.254.227] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MA1PR0101MB1784; 6:+traO90XF0hzGeDTNwsG8iDcQZ7GR/Ocjckvf6a1qYa8ji5Jozq2fZw5en3HznIKAsdECn1sF5wi7VkS0zaBi+eo33BOOHhIC/6OlS8rd0k0wFXCSiyj4ytJt+0BE+pcx4ht0mX2smL8sN7yEQSvPUr7ZESrPpz0UvV1Li/PrGLulWlntQJ+4K8UXF+YEuGKu5U/7Lm6A8NXO5kaIg8MyfuNtiLRNEn/pYh3HzsHRKSimkDlmtITQFYqbfViNpmgWbslF5Y5uccgvomFCdJG00xG8sRltpV6YtEEb3e7ziWx+b9f/amjN8Q/0V06AvTtAFIzKgiCyuPoT73yNHS5powcyyRrm5wE4FrvV3WtH6nidSR254eH4ImBIhY+2JOk; 5:lBR6rqOkgp7dF9OpDayreJIt0R4KqTqrQ4lVGgizkOLYn5yG2eYKMmnKfFf2L4FvP92y/SdDbRK6Cys/Cat/3j2UA+8x7b9Tk4QXXBTSZZukb73K46IcVY0QEYQ3oHBGFzBATnQwBU1f47zmFvQrKgwGlNrAOvMe3G/DaipYWq8=; 24:uMUKuPiyt2QILUjBqfrRX/TRf+aB3l4Q/h8nrCv8qWQOHHyI56YZeVjXZxlHAAcLJj6ORDGv90qKLHZga6RxKH00kVxwsUlD/SpSEb6+1UM=; 7:7ZaD3lTu1QekszAJq2DMdvRxVcCnUX76G47WOMXoDvBoJwc4Ql2gNEGK2t/HagxWZ6v5j5Vn+lARnhF4aJbyDRfqgzmaoz6g5pJq5ruIse2vUGTiDagdweFwcUhhiEAvw1ovQrZVpSjpCht2S7Cpb7DTwgBoBeiStWl4K9McccKlFBDtT6UuuVhKALwQ3KT/I1XY6LrHPNY0g5CiwU7YioH6AjdKSpx0UvU8e+tqJVpg/Jfax6DvMnbUNKId3O2r x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 56c41ba0-26a8-40d3-bc2a-08d55669d6e3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MA1PR0101MB1784; x-ms-traffictypediagnostic: MA1PR0101MB1784: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6055026)(6041268)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:MA1PR0101MB1784; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MA1PR0101MB1784; x-forefront-prvs: 054642504A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(39380400002)(396003)(366004)(346002)(376002)(199004)(189003)(38564003)(54896002)(6916009)(2950100002)(478600001)(76176011)(8936002)(59450400001)(5660300001)(9326002)(7696005)(81166006)(72206003)(25786009)(99286004)(81156014)(6116002)(3846002)(8676002)(5640700003)(3280700002)(68736007)(4743002)(14454004)(55016002)(6436002)(6306002)(53936002)(2501003)(9686003)(102836004)(6506007)(3660700001)(66066001)(2940100002)(105586002)(2906002)(2900100001)(33656002)(74316002)(106356001)(2351001)(230783001)(97736004)(5250100002)(86362001)(7736002)(316002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:MA1PR0101MB1784; H:MA1PR0101MB1783.INDPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: aricent.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Bo6lHLmckSmHBme5z9KZ65HKsPs/XtF8w79f8O9GFnoELGdCw7Jbe87As3Wvj66EZipI2JprikcLyBLvF9t/dQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MA1PR0101MB17836897B1F416B16D195F96FC130MA1PR0101MB1783_" MIME-Version: 1.0 X-OriginatorOrg: Aricent.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56c41ba0-26a8-40d3-bc2a-08d55669d6e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2018 07:31:31.7409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dbb4cbbe-57c5-469d-b342-a9814e1d2382 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MA1PR0101MB1784 Archived-At: X-Mailman-Approved-At: Mon, 08 Jan 2018 00:36:26 -0800 Subject: [L2sm] draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 07:31:44 -0000 --_000_MA1PR0101MB17836897B1F416B16D195F96FC130MA1PR0101MB1783_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The way contains are organized in this service model will cause problems fo= r software implementation. To identify Sites associated with a service, implementation shall iterate a= ll the sites list. Also VPLS kind of services when orchestrator is sending = service creation request to SDN Controller Application, then when shall app= lication assume that all Sites have been received. A slightly modified organization shall help getting rid of above problems. = Please suggest. Current Organization of Yang: container l2vpn-svc { container vpn-profiles { uses vpn-profile-cfg; } container vpn-services { list vpn-svc { key "vpn-id"; leaf vpn-id { type svc-id; description "Defining a service id."; } leaf vpn-svc-type { type identityref { base service-type; } description "Service type"; } leaf customer-name { type string; description "Customer name"; } leaf svc-topo { type identityref { base vpn-topology; } .... } } container sites { list site { key "site-id site-type"; leaf site-id { type string; description "Site id"; } ... } } } Proposed Organization of Yang: container l2vpn-svcs { list l2vpn-svc { key "vpn-id"; leaf vpn-id { type svc-id; description "Defining a service id."; } container vpn-services { leaf vpn-svc-type { type identityref { base service-type; } description "Service type"; } leaf customer-name { type string; description "Customer name"; } leaf svc-topo { type identityref { base vpn-topology; } .... } container sites { list site { key "site-id site-type"; leaf site-id { type string; description "Site id"; } ... } } } Regards Ashish Mittal "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_MA1PR0101MB17836897B1F416B16D195F96FC130MA1PR0101MB1783_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

The way contains are organized in this service model= will cause problems for software implementation.

 

To identify Sites associated with a service, impleme= ntation shall iterate all the sites list. Also VPLS kind of services when o= rchestrator is sending service creation request to SDN Controller Applicati= on, then when shall application assume that all Sites have been received.

 

A slightly modified organization shall help getting = rid of above problems. Please suggest.

 

Current Organization of Yang:

 

container l2vpn-svc {

container vpn-profiles {<= o:p>

uses vpn-profile-cfg;

}

container vpn-services {<= o:p>

list vpn-svc {

key "vpn-id";<= o:p>

leaf vpn-id {=

type svc-id;<= /p>

description

"Defining a service= id.";

}

leaf vpn-svc-type {=

type identityref {<= /o:p>

base service-type;<= /o:p>

}

description

"Service type"= ;

}

leaf customer-name {

type string;<= /p>

description

"Customer name"= ;;

}

leaf svc-topo {

type identityref {<= /o:p>

base vpn-topology;<= /o:p>

}

….

}

}

 

container sites {

list site {

key "site-id site-t= ype";

leaf site-id {

type string;<= /p>

description

"Site id";

}

…

}

}

}

 

Proposed Organization of Yang:

 

container l2vpn-svcs

{

        &= nbsp;      list l2vpn-svc

        &= nbsp;      {

key "vpn-id";<= o:p>

leaf vpn-id {=

type svc-id;<= /p>

description

"Defining a service= id.";

}

    &= nbsp;          container vpn-s= ervices {

    =            leaf vpn-svc-t= ype {

type identityref {<= /o:p>

base service-type;<= /o:p>

}

description

"Service type"= ;

}

leaf customer-name {

type string;<= /p>

description

"Customer name"= ;;

}

leaf svc-topo {

type identityref {<= /o:p>

base vpn-topology;<= /o:p>

}

….

    &= nbsp;          }

    &= nbsp;          container sites=

    &= nbsp;          {

list site {

key "site-id site-t= ype";

leaf site-id {

type string;<= /p>

description

"Site id";

}

…

}

        &= nbsp;      }

}

 

Regards

 

Ashish Mittal

 

"DISCLAIMER: This message is proprietary to Aricent and is intended so= lely for the use of the individual to whom it is addressed. It may contain = privileged or confidential information and should not be circulated or used= for any purpose other than for what it is intended. If you have received this message in error, please notify = the originator immediately. If you are not the intended recipient, you are = notified that you are strictly prohibited from using, copying, altering, or= disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from= the use of the information transmitted by this email including damage from= virus." --_000_MA1PR0101MB17836897B1F416B16D195F96FC130MA1PR0101MB1783_-- From nobody Thu Jan 11 08:26:47 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B32F12D811 for ; Thu, 11 Jan 2018 08:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bsyy0gWCRB2O for ; Thu, 11 Jan 2018 08:26:41 -0800 (PST) Received: from mx03.telecomitalia.it (mx03.telecomitalia.it [217.169.121.23]) (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 5F38012EBC9 for ; Thu, 11 Jan 2018 08:26:40 -0800 (PST) X-AuditID: d9a97917-0d7ff70000001050-58-5a57903db5f7 Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx03.telecomitalia.it () with SMTP id 1B.84.04176.D30975A5; Thu, 11 Jan 2018 17:26:37 +0100 (CET) From: Fioccola Giuseppe To: Ashish Mittal , "l2sm@ietf.org" Thread-Topic: [L2sm] draft-ietf-l2sm-l2vpn-service-model Thread-Index: AQHTiFvJYMZZDShFK06eRhR2BKCVyaNu21MA Date: Thu, 11 Jan 2018 16:26:37 +0000 Message-ID: <0d91c98bf35c4682995ed43ab68f28cb@TELMBXB02RM001.telecomitalia.local> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.240] x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_0d91c98bf35c4682995ed43ab68f28cbTELMBXB02RM001telecomit_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPKsWRmVeSWpSXmKPExsXCxfdHStd2QniUQctvFYvzW+axWtx5+ZLR gcljy/8trB5LlvxkCmCKamC0SczLyy9JLElVSEktTrZVcsksTs5JzMxNLVIISc1JTc7PVVLI TLFVMlZSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+uhYWppa6 hkp2gaWpxSX5CrmpxcWJ6emZ+QqpCesFM379PspW0LmQseL37Y3sDYx/+hm7GDk5JARMJJa9 2wBkc3EICUxhkvg1dT8zSIJNwEbi4KsTbCC2iICfxLOdb8EahAXMJN627ASq4QCKW0jc+1YA UWIksXXZElYQm0VAVWL7jztgY3gFAiXOb13EDjF/O6PEm01zWUASnAKJEvevt4PNZxSQlZiw exHYfGYBcYkX00+wQxwnILFkz3lmCFtU4uXjf6wQtoHE1qX7WCBsRYmtn2DqZSQWHpnMCjEn X2LBh2XsEEcISpyc+YRlAqPILCQrZiEpm4WkDCKuJ3Fj6hQ2CFtbYtnC18wQtq7EjH+HWJDF FzCyr2IUza0wMNYrgcRmZkliTmaiXmbJJkZgKrm5slJ8B2P7SudDjAIcjEo8vIsaw6OEWBPL iitzDzFKcDArifDWdAOFeFMSK6tSi/Lji0pzUosPMfoAg3Iis5Rocj4wzeWVxBuaWFgaGltY GBlamJniEFYS55XNApolkA5MbtmpqQWpRTDjmDg4pRoYSwvSbRSLLL66HVewUZ25RLOz9e4S h4PWH/8t2VvbuHnuPePWRduy89Zm/KpS3nZD8F/ZDWOzaVyOM3Q5Std5VsdfMW5QPj1JvHqz xlwpIY2V7vVT1stVvHMPEq2WX35wg3+N5tueBZnK9ub/1OK0nj0/OnWezNMKkVvyPU3zVl1n DouUneylxFKckWioxVxUnAgAzDClfFIDAAA= Archived-At: Subject: [L2sm] R: draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 16:26:46 -0000 --_000_0d91c98bf35c4682995ed43ab68f28cbTELMBXB02RM001telecomit_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ashish, (I'm resending my answer in order to involve in the discussion the whole L2S= M WG) Thanks for your comments! I understand your point and I will consider it. We are working on a new revi= sion. Regarding sites and services identification, our intent is to model L2SM in= the same way as L3SM, in order to have a common structure for L2SM/L3SM. Best Regards, Giuseppe Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di Ashish Mittal Inviato: luned=EC 8 gennaio 2018 08:32 A: l2sm@ietf.org Oggetto: [L2sm] draft-ietf-l2sm-l2vpn-service-model Hello, The way contains are organized in this service model will cause problems for= software implementation. To identify Sites associated with a service, implementation shall iterate al= l the sites list. Also VPLS kind of services when orchestrator is sending se= rvice creation request to SDN Controller Application, then when shall applic= ation assume that all Sites have been received. A slightly modified organization shall help getting rid of above problems. P= lease suggest. Current Organization of Yang: container l2vpn-svc { container vpn-profiles { uses vpn-profile-cfg; } container vpn-services { list vpn-svc { key "vpn-id"; leaf vpn-id { type svc-id; description "Defining a service id."; } leaf vpn-svc-type { type identityref { base service-type; } description "Service type"; } leaf customer-name { type string; description "Customer name"; } leaf svc-topo { type identityref { base vpn-topology; } .... } } container sites { list site { key "site-id site-type"; leaf site-id { type string; description "Site id"; } ... } } } Proposed Organization of Yang: container l2vpn-svcs { list l2vpn-svc { key "vpn-id"; leaf vpn-id { type svc-id; description "Defining a service id."; } container vpn-services { leaf vpn-svc-type { type identityref { base service-type; } description "Service type"; } leaf customer-name { type string; description "Customer name"; } leaf svc-topo { type identityref { base vpn-topology; } .... } container sites { list site { key "site-id site-type"; leaf site-id { type string; description "Site id"; } ... } } } Regards Ashish Mittal "DISCLAIMER: This message is proprietary to Aricent and is intended solely f= or the use of the individual to whom it is addressed. It may contain privile= ged or confidential information and should not be circulated or used for any= purpose other than for what it is intended. If you have received this messa= ge in error, please notify the originator immediately. If you are not the in= tended recipient, you are notified that you are strictly prohibited from usi= ng, copying, altering, or disclosing the contents of this message. Aricent a= ccepts no responsibility for loss or damage arising from the use of the info= rmation transmitted by this email including damage from virus." Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. --_000_0d91c98bf35c4682995ed43ab68f28cbTELMBXB02RM001telecomit_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ashis= h,

(I’= ;m resending my answer in order to involve in the discussion the whole L2SM= WG)

Thanks f= or your comments!

I unders= tand your point and I will consider it. We are working on a new revision.

Regardin= g sites and services identification, our intent is to model L2SM in the same= way as L3SM, in order to have a common structure for L2SM/L3SM.<= /span>

&nb= sp;

Best Reg= ards,

&nb= sp;

Giuseppe=

 

Da: L2sm [mai= lto:l2sm-bounces@ietf.org] Per conto di Ashish Mittal
Inviato: luned=EC 8 gennaio 2018 08:32
A: l2sm@ietf.org
Oggetto: [L2sm] draft-ietf-l2sm-l2vpn-service-model=

 

Hello,

 

The way contains are organized i= n this service model will cause problems for software implementation.

 

To identify Sites associated wit= h a service, implementation shall iterate all the sites list. Also VPLS kind= of services when orchestrator is sending service creation request to SDN Co= ntroller Application, then when shall application assume that all Sites have been received.

 

A slightly modified organization= shall help getting rid of above problems. Please suggest.=

 

Current Organization of Yang:=

 

container l2vpn-svc {=

con= tainer vpn-profiles {

use= s vpn-profile-cfg;

}

con= tainer vpn-services {

lis= t vpn-svc {

ke= y "vpn-id";

le= af vpn-id {

ty= pe svc-id;

de= scription

&q= uot;Defining a service id.";

}<= o:p>

le= af vpn-svc-type {

ty= pe identityref {

ba= se service-type;

}<= o:p>

de= scription

&q= uot;Service type";

}<= o:p>

le= af customer-name {

ty= pe string;

de= scription

&q= uot;Customer name";

}<= o:p>

le= af svc-topo {

ty= pe identityref {

ba= se vpn-topology;

}<= o:p>

&#= 8230;.

}

}

 

con= tainer sites {

lis= t site {

ke= y "site-id site-type";

le= af site-id {

ty= pe string;

de= scription

&q= uot;Site id";

}<= o:p>

&#= 8230;

}

}

}

 

Proposed Organization of Yang= :

 <= /p>

container l2vpn-svcs =

{

     = ;          list l2vpn-svc<= /o:p>

     = ;          {<= /b>

key= "vpn-id";

lea= f vpn-id {

typ= e svc-id;

des= cription

&qu= ot;Defining a service id.";

}

&nb= sp;            &= nbsp; container vpn-services {

&nb= sp;            &= nbsp; leaf vpn-svc-type {

ty= pe identityref {

ba= se service-type;

}<= o:p>

de= scription

&q= uot;Service type";

}<= o:p>

le= af customer-name {

ty= pe string;

de= scription

&q= uot;Customer name";

}<= o:p>

le= af svc-topo {

ty= pe identityref {

ba= se vpn-topology;

}<= o:p>

&#= 8230;.

&nb= sp;            &= nbsp; }

&nb= sp;            &= nbsp; container sites

&nb= sp;            &= nbsp; {

li= st site {

ke= y "site-id site-type";

le= af site-id {

ty= pe string;

de= scription

&q= uot;Site id";

}<= o:p>

&#= 8230;

}

     = ;          }<= /b>

}

 

Regards

 

Ashish Mittal<= /p>

 

"DISCLAIMER: This= message is proprietary to Aricent and is intended solely for the use of the= individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any pu= rpose other than for what it is intended. If you have received this message= in error, please notify the originator immediately. If you are not the inte= nded recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosi= ng the contents of this message. Aricent accepts no responsibility for loss= or damage arising from the use of the information transmitted by this email= including damage from virus."

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle= persone indicate. La diffusione, copia o qualsiasi altra azione derivante d= alla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a= bbiate ricevuto questo documento per errore siete cortesemente pregati di da= rne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.

This e-mail and any attachments is confidential and may contain privil= eged information intended for the addressee(s) only. Dissemination, copying,= printing or use by anybody else is unauthorised. If you are not the intende= d recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessa= rio.
--_000_0d91c98bf35c4682995ed43ab68f28cbTELMBXB02RM001telecomit_-- From nobody Tue Jan 16 01:46:20 2018 Return-Path: X-Original-To: l2sm@ietf.org Delivered-To: l2sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA39312FB3A; Tue, 16 Jan 2018 01:46:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: l2sm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151609596981.11653.14451666326960850647@ietfa.amsl.com> Date: Tue, 16 Jan 2018 01:46:09 -0800 Archived-At: Subject: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-05.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 09:46:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the L2VPN Service Model WG of the IETF. Title : A YANG Data Model for L2VPN Service Delivery Authors : Bin Wen Giuseppe Fioccola Chongfeng Xie Luay Jalil Filename : draft-ietf-l2sm-l2vpn-service-model-05.txt Pages : 149 Date : 2018-01-16 Abstract: This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The data model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-05 https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-l2sm-l2vpn-service-model-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 16 02:05:21 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963D012D956; Tue, 16 Jan 2018 02:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lor6IYKy-vyQ; Tue, 16 Jan 2018 02:05:16 -0800 (PST) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (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 394AC12FB48; Tue, 16 Jan 2018 02:04:58 -0800 (PST) X-AuditID: d9a97916-36fff70000001046-08-5a5dce483553 Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id BB.1C.04166.84ECD5A5; Tue, 16 Jan 2018 11:04:56 +0100 (CET) From: Fioccola Giuseppe To: "l2sm@ietf.org" CC: "l2sm-chairs@ietf.org" , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" Thread-Topic: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-05.txt Thread-Index: AQHTjq7w/x/jwmExYkKgEw6VlPJWz6N2QKfg Date: Tue, 16 Jan 2018 10:04:55 +0000 Message-ID: <2a68b07f1ac1484eb7ec92ce8b3d24c3@TELMBXB02RM001.telecomitalia.local> References: <151609596981.11653.14451666326960850647@ietfa.amsl.com> In-Reply-To: <151609596981.11653.14451666326960850647@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.248] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsXCxfdHWtfjXGyUwfdlghY9jxuZLB7svMhm ceflS0YHZo8lS34yBTBGNTDaJObl5ZcklqQqpKQWJ9squWQWJ+ckZuamFimEpOakJufnKilk ptgqGSspFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/XQsLU0td QyW7wNLU4pJ8hdzU4uLE9PTMfIXUhPWCGStXPmcseKtace/1PpYGxhmyXYwcHBICJhL/nnJ3 MXJyCAlMYZL4ekkSxGYTsJE4+OoEG4gtIqAssfVZByuIzSwwhVFi+wkLEFtYwFPi7Y9lzBA1 3hLHV2+HqjeS2DhtBSPIeBYBVYnZ3YogYV6BQIm+f8vZIVa5SFyZ/w+slVPAVeLPvhNg4xkF ZCUm7F7ECLFKXOLF9BNg9RICAhJL9pxnhrBFJV4+/scKYRtIbF26jwXCVpSYtOI3VL2MxMIj k6FO1pO4MXUKG4StLbFs4WtmiHsEJU7OfMIygVFsFpJ1s5C0zELSMgtJywJGllWMorkVBkZ6 JZDIyyxJzMlM1Mss2cQITBQ3V1aK7WBsXet8iFGAg1GJh7evPzZKiDWxrLgy9xCjBAezkghv Y3BMlBBvSmJlVWpRfnxRaU5q8SFGH2CATWSWEk3OByaxvJJ4QxMLS0NjCwsjQwszUxzCSuK8 j04DjRdIB6au7NTUgtQimHFMHJxSDYya35es4bvx4qC9ztGpNxM6WLO9wz4KzdjCzrjx4Pop 3GxSCpr3Dm1doqJ6bZuZ+UdNLqs1h0+9W79FfZa8hkTo1cIXW/hu5NpYrtdoX1S7v2wte+l6 CbE1P/w0Pp67FbvpoqJ624Ttyya0nevibe5nvvDJ2l5PlXmN78HrlZc//3DJW850/WeKEktx RqKhFnNRcSIAvKw6hEEDAAA= Archived-At: Subject: [L2sm] I: I-D Action: draft-ietf-l2sm-l2vpn-service-model-05.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 10:05:20 -0000 Hi All, This is the new version of the draft-ietf-l2sm-l2vpn-service-model. It addresses some comments from people that are trying to implement the draf= t and it includes also an update to the references in particular to RFC8199= and RFC8309. As usual, the fundamental changes are summarized in the Appendix A "Changes= Log": Changes in v-(05) include: o Change type from 16-bit integer to string for the leaf id under "qos-classification-policy" container. o Stick to using ordered-by user and remove inefficiency to map service model sequence number to device model sequence number. o Remove mandating the use of deviations and add "if-feature target- sites" under the leaf-list target-sites in section 5.10.2. o RFC2119 language changes on operation of the management system in Section 5.6,3rd paragraph and section 7. o Fix incomplete description statements. o Change the use of the absolute paths to the use of relative paths in the "must" statement or "path" statement for vpn-policy-id leaf node, management container, location leaf node, devices container, location case, location-reference leaf, device case, device- reference leaf to make configuration is only applicable to the current sites. o Change "must" statement to "when" statement for management container device container. o Define new grouping vpn-profile-cfg for all the identifiers provided by SP to the customer. The identifiers include cloud- identifier, std-qos-profile. o Add in the XPATH string representation and remove unqualified name. o Remove redundant parameters in the cloud access. o Add a few text to clarify what the site is in section 6.3. o Add multi-filter and multi-VPN per entry support for VPN policy. o Modify description for svc-bandwidth leaf to make it consistent with the text in section 5.10.1. o Add text to clarify the way to achieve Per-VPN QoS policy. o Change guaranteed-bw-percent data type from uint8 to decimal64. Reviews and Comments are always welcome. Best Regards, Giuseppe -----Messaggio originale----- Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di internet-drafts@ietf.or= g Inviato: marted=EC 16 gennaio 2018 10:46 A: i-d-announce@ietf.org Cc: l2sm@ietf.org Oggetto: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directori= es. This draft is a work item of the L2VPN Service Model WG of the IETF. Title : A YANG Data Model for L2VPN Service Delivery Authors : Bin Wen Giuseppe Fioccola Chongfeng Xie Luay Jalil Filename : draft-ietf-l2sm-l2vpn-service-model-05.txt Pages : 149 Date : 2018-01-16 Abstract: This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The data model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-05 https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2sm-l2vpn-service-model-05 Please note that it may take a couple of minutes from the time of submission= until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ L2sm mailing list L2sm@ietf.org https://www.ietf.org/mailman/listinfo/l2sm Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. From nobody Wed Jan 17 01:02:23 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA55C12FA93; Wed, 17 Jan 2018 01:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id id0k249QDKQ9; Wed, 17 Jan 2018 01:02:14 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4673212FAB6; Wed, 17 Jan 2018 01:02:07 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0H92273007146; Wed, 17 Jan 2018 09:02:02 GMT Received: from 950129200 ([193.56.243.68]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0H920Ua007140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2018 09:02:01 GMT Reply-To: From: "Adrian Farrel" To: Cc: , , Date: Wed, 17 Jan 2018 09:01:57 -0000 Message-ID: <058701d38f71$d52d2b60$7f878220$@olddog.co.uk> 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: AdOPcdHzLYFpStp2Tc6QYweOw1cpSQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23600.005 X-TM-AS-Result: No--33.408-10.0-31-10 X-imss-scan-details: No--33.408-10.0-31-10 X-TMASE-MatchedRID: rPZRCuzwEyz7PYirXBVD5M98NT1MWuHvQPCWRE0Lo8K67Q3uPo9KI+H7 ZfhCofggcK5QyD9bSliKafM1hOxh+YjQo/Iw2s1SgOqr/r0d+CyLH4rzyQtUPY5t/XRqktxJwua niM9QXy013oPvTQ6OMo913mjfQ3KIHodpx3o6Gru4jAucHcCqneiY+s2L3xQEhn2bbI5joUWkDb FjTQ0CSi2Cn8nZ5xCf5g00vvdy6HqY+dHsEP/MFWMGiV639iF0Yu7s3QSSN+SQ2TbICkFOdmqMd wbSsCOujPVpVub5F3FmVMg6wIiaxg9FV6kNYiPHhCecAVGCOf0C5AMlEyiBEigMxnfFXjiIEmiH uEfayulqI3Rvf0ZV0LRzzYR4U4nd64YUNtZYBWEYBkxPlIuYCZqCl1R34jDPbcPp/oilsshxkDa YjAh4s8vnSCXBRWs5pp57/9F4tS94Bq+n7hYcraVzYsvffdUx5T1HpvyeXOQF9YmkHybWAHGtwv y18aR/EBDoMW2sVrCe8jJanTz+4rcH4/RZ7lQnCLNfGU4dffgZKp0SZ4P+dbNcuCb8CAxu0ISbJ BSoCMNhJ5Zyqn1oSzXysAHc5MpBs+KpsQUlyYXG693ff8j9ZJZ6zKu0q4rtfUOf4Mp5xtYu6lmG akqVh5j8YEB3JMRbGhSpfcKQYBSqYtZoSKdB4QtigoE0Deb+J/dPdoLAWDmh89mqiZyndkr24C3 H1DCPa2r3qllpBgBPgpGv/Pbptxcy5bypFl2Lqbg9uWhLYLf76a7w2Q6CXif663Ll9ACjayz+lI iY36jgFNHYA/U/9YNgn0LpDR/v+RahkyeUE56eAiCmPx4NwGNn8XPiALIb+gD2vYtOFhgqtq5d3 cxkNQwWxr7XDKH8lExlQIQeRG0= Archived-At: Subject: [L2sm] Next steps with draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2018 09:02:22 -0000 All, We're approaching Working Groups last call on our draft. - I have requested a YANG Doctor review of the current revision - I plan to do an English language review at the same time (unless someone else want to volunteer) - NOW is the time for you to do your technical review. Don't leave is until WG last call! - All things being equal, we will have WG last call in early February Thanks, Adrian > -----Original Message----- > From: L2sm [mailto:l2sm-bounces@ietf.org] On Behalf Of Fioccola = Giuseppe > Sent: 16 January 2018 10:05 > To: l2sm@ietf.org > Cc: draft-ietf-l2sm-l2vpn-service-model@ietf.org; l2sm-chairs@ietf.org > Subject: [L2sm] I: I-D Action: = draft-ietf-l2sm-l2vpn-service-model-05.txt >=20 > Hi All, > This is the new version of the draft-ietf-l2sm-l2vpn-service-model. > It addresses some comments from people that are trying to implement = the draft > and it includes also an update to the references in particular to = RFC8199 and > RFC8309. > As usual, the fundamental changes are summarized in the Appendix A = "Changes > Log": >=20 > Changes in v-(05) include: >=20 > o Change type from 16-bit integer to string for the leaf id under > "qos-classification-policy" container. >=20 > o Stick to using ordered-by user and remove inefficiency to map > service model sequence number to device model sequence number. >=20 > o Remove mandating the use of deviations and add "if-feature = target- > sites" under the leaf-list target-sites in section 5.10.2. >=20 > o RFC2119 language changes on operation of the management system = in > Section 5.6,3rd paragraph and section 7. >=20 > o Fix incomplete description statements. >=20 > o Change the use of the absolute paths to the use of relative = paths > in the "must" statement or "path" statement for vpn-policy-id = leaf > node, management container, location leaf node, devices = container, > location case, location-reference leaf, device case, device- > reference leaf to make configuration is only applicable to the > current sites. >=20 > o Change "must" statement to "when" statement for management > container device container. >=20 > o Define new grouping vpn-profile-cfg for all the identifiers > provided by SP to the customer. The identifiers include cloud- > identifier, std-qos-profile. >=20 > o Add in the XPATH string representation and remove unqualified > name. >=20 > o Remove redundant parameters in the cloud access. >=20 > o Add a few text to clarify what the site is in section 6.3. >=20 > o Add multi-filter and multi-VPN per entry support for VPN policy. >=20 > o Modify description for svc-bandwidth leaf to make it consistent > with the text in section 5.10.1. >=20 > o Add text to clarify the way to achieve Per-VPN QoS policy. >=20 > o Change guaranteed-bw-percent data type from uint8 to decimal64. >=20 >=20 > Reviews and Comments are always welcome. >=20 > Best Regards, >=20 > Giuseppe >=20 > -----Messaggio originale----- > Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di = internet-drafts@ietf.org > Inviato: marted=EC 16 gennaio 2018 10:46 > A: i-d-announce@ietf.org > Cc: l2sm@ietf.org > Oggetto: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the L2VPN Service Model WG of the IETF. >=20 > Title : A YANG Data Model for L2VPN Service Delivery > Authors : Bin Wen > Giuseppe Fioccola > Chongfeng Xie > Luay Jalil > Filename : draft-ietf-l2sm-l2vpn-service-model-05.txt > Pages : 149 > Date : 2018-01-16 >=20 > Abstract: > This document defines a YANG data model that can be used to = configure > a Layer 2 Provider Provisioned VPN service. >=20 > This model is intended to be instantiated at management system to > deliver the overall service. This model is not a configuration = model > to be used directly on network elements, but provides an abstracted > view of the Layer 2 VPN service configuration components. It is up > to a management system to take this as an input and generate = specific > configurations models to configure the different network elements = to > deliver the service. How configuration of network elements is done > is out of scope of the document. >=20 > The data model in this document includes support for point-to-point > Virtual Private Wire Services (VPWS) and multipoint Virtual Private > LAN services (VPLS) that use Pseudowires signaled using the Label > Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) = as > described in RFC4761 and RFC6624. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model= -05 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2sm-l2vpn-service-model-0= 5 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > L2sm mailing list > L2sm@ietf.org > https://www.ietf.org/mailman/listinfo/l2sm >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone > indicate. La diffusione, copia o qualsiasi altra azione derivante = dalla conoscenza di > queste informazioni sono rigorosamente vietate. Qualora abbiate = ricevuto > questo documento per errore siete cortesemente pregati di darne = immediata > comunicazione al mittente e di provvedere alla sua distruzione, = Grazie. >=20 > This e-mail and any attachments is confidential and may contain = privileged > information intended for the addressee(s) only. Dissemination, = copying, printing > or use by anybody else is unauthorised. If you are not the intended = recipient, > please delete this message and any attachments and advise the sender = by return > e-mail, Thanks. >=20 > Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. >=20 > _______________________________________________ > L2sm mailing list > L2sm@ietf.org > https://www.ietf.org/mailman/listinfo/l2sm From nobody Sat Jan 20 22:23:29 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715361270B4; Sat, 20 Jan 2018 22:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nxYqZ6EveLA; Sat, 20 Jan 2018 22:23:24 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43626126CD8; Sat, 20 Jan 2018 22:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11098; q=dns/txt; s=iport; t=1516515804; x=1517725404; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rtn8o3Mo+A/15jKJkQ+04E1CAElOQARB4ruygVTAzcY=; b=cCII8ERqHwWOyBUMuj3zrRjfWkbljcpjn0yCFt6KOzoH52WBJ4dRBXfo UZ1bwaNMmZsR6sYHGeRdDwq01WmPcuIVdhvicGp578gE20rhWrD35+O5y lRxJRYByTd0zyRa+07BszLWMoQVpV2SJ0v0+5LQG8mXeUoKT6WsXwsEx3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AgCbMWRa/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMRMWZ0JweDVpkEggJ8lkKCFwoYDYUWAhqESUAXAQEBAQEBAQE?= =?us-ascii?q?Bax0LhSMBAQEEAQEhEToEBwwEAgEIEQQBAQMCIwMCAgIlCxQBCAgBAQQOBYozE?= =?us-ascii?q?LIvgieKJgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BD4M6gTVggVdsfCmCTzaDLwE?= =?us-ascii?q?BAgEBF4E2AQE1FYJrMYI0BYpfh1KRSQKIEY1IghtnhTiLZYp1glyJSQIRGQGBO?= =?us-ascii?q?wEhATaBUG8VGSQqAYF/CYJQF4FneIg9gSWBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,390,1511827200"; d="scan'208";a="59452798" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2018 06:23:15 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w0L6NED0005269 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 21 Jan 2018 06:23:15 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 21 Jan 2018 01:23:14 -0500 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1320.000; Sun, 21 Jan 2018 01:23:14 -0500 From: "Roque Gagliano (rogaglia)" To: "adrian@olddog.co.uk" CC: "Benoit Claise (bclaise)" , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" , "l2sm@ietf.org" , "l2sm-chairs@ietf.org" Thread-Topic: [L2sm] Next steps with draft-ietf-l2sm-l2vpn-service-model Thread-Index: AdOPcdHzLYFpStp2Tc6QYweOw1cpSQDQMlGA Date: Sun, 21 Jan 2018 06:23:13 +0000 Message-ID: <47CEAC7E-BCD8-4B93-BB2A-2EFACDD55223@cisco.com> References: <058701d38f71$d52d2b60$7f878220$@olddog.co.uk> In-Reply-To: <058701d38f71$d52d2b60$7f878220$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.28.0.171108 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.167.103] Content-Type: text/plain; charset="utf-8" Content-ID: <1268386DA30427489F7DD6B25140AC62@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [L2sm] Next steps with draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 06:23:27 -0000 SGkgQWRyaWFuLA0KDQpPbmUgcG9pbnQgdGhhdCBJIHdvdWxkIGxpa2UgdG8gcmFpc2UgaXMgdGhh dCBpdCB3b3VsZCBiZSBpbXBvcnRhbnQgdG8gZGVzY3JpYmUgdGhlIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIHRoaXMgd29yayBhbmQgd2hhdCBpcyBoYXBwZW5pbmcgYXQgb3RoZXIgc3RhbmRhcmRpemF0 aW9uIGJvZGllcyBzdWNoIGFzIHRoZSBNRUYgTGVnYXRvIFlBTkcgc2VydmljZSBtb2R1bGVzIGFu ZCB0aGUgVEFQSSB3b3JrIGF0IHRoZSBPTkYuDQoNClJlZ2FyZHMsDQpSb3F1ZQ0KDQpSZWYgTUVG IExlZ2F0byBZQU5HIG1vZHVsZXM6IGh0dHBzOi8vZ2l0aHViLmNvbS9NRUYtR0lUL1lBTkctcHVi bGljL3RyZWUvbWFzdGVyL3NyYy9tb2RlbC9kcmFmdA0KDQoNCk9uIDE3LzAxLzE4IDEwOjAyLCAi TDJzbSBvbiBiZWhhbGYgb2YgQWRyaWFuIEZhcnJlbCIgPGwyc20tYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgYWRyaWFuQG9sZGRvZy5jby51az4gd3JvdGU6DQoNCiAgICBBbGwsDQogICAg DQogICAgV2UncmUgYXBwcm9hY2hpbmcgV29ya2luZyBHcm91cHMgbGFzdCBjYWxsIG9uIG91ciBk cmFmdC4NCiAgICANCiAgICAtIEkgaGF2ZSByZXF1ZXN0ZWQgYSBZQU5HIERvY3RvciByZXZpZXcg b2YgdGhlIGN1cnJlbnQgcmV2aXNpb24NCiAgICAtIEkgcGxhbiB0byBkbyBhbiBFbmdsaXNoIGxh bmd1YWdlIHJldmlldyBhdCB0aGUgc2FtZSB0aW1lICh1bmxlc3MNCiAgICAgICBzb21lb25lIGVs c2Ugd2FudCB0byB2b2x1bnRlZXIpDQogICAgLSBOT1cgaXMgdGhlIHRpbWUgZm9yIHlvdSB0byBk byB5b3VyIHRlY2huaWNhbCByZXZpZXcuIERvbid0IGxlYXZlDQogICAgICAgaXMgdW50aWwgV0cg bGFzdCBjYWxsIQ0KICAgIC0gQWxsIHRoaW5ncyBiZWluZyBlcXVhbCwgd2Ugd2lsbCBoYXZlIFdH IGxhc3QgY2FsbCBpbiBlYXJseSBGZWJydWFyeQ0KICAgIA0KICAgIFRoYW5rcywNCiAgICANCiAg ICBBZHJpYW4NCiAgICANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiBG cm9tOiBMMnNtIFttYWlsdG86bDJzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRmlv Y2NvbGEgR2l1c2VwcGUNCiAgICA+IFNlbnQ6IDE2IEphbnVhcnkgMjAxOCAxMDowNQ0KICAgID4g VG86IGwyc21AaWV0Zi5vcmcNCiAgICA+IENjOiBkcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2Vydmlj ZS1tb2RlbEBpZXRmLm9yZzsgbDJzbS1jaGFpcnNAaWV0Zi5vcmcNCiAgICA+IFN1YmplY3Q6IFtM MnNtXSBJOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC0w NS50eHQNCiAgICA+IA0KICAgID4gSGkgQWxsLA0KICAgID4gVGhpcyBpcyB0aGUgbmV3IHZlcnNp b24gb2YgdGhlIGRyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLg0KICAgID4gSXQg YWRkcmVzc2VzIHNvbWUgY29tbWVudHMgZnJvbSBwZW9wbGUgdGhhdCBhcmUgdHJ5aW5nIHRvIGlt cGxlbWVudCB0aGUgZHJhZnQNCiAgICA+IGFuZCBpdCBpbmNsdWRlcyBhbHNvIGFuIHVwZGF0ZSB0 byB0aGUgcmVmZXJlbmNlcyBpbiBwYXJ0aWN1bGFyIHRvIFJGQzgxOTkgYW5kDQogICAgPiBSRkM4 MzA5Lg0KICAgID4gQXMgdXN1YWwsIHRoZSBmdW5kYW1lbnRhbCBjaGFuZ2VzIGFyZSBzdW1tYXJp emVkIGluIHRoZSBBcHBlbmRpeCBBICJDaGFuZ2VzDQogICAgPiBMb2ciOg0KICAgID4gDQogICAg PiAgICBDaGFuZ2VzIGluIHYtKDA1KSBpbmNsdWRlOg0KICAgID4gDQogICAgPiAgICBvICBDaGFu Z2UgdHlwZSBmcm9tIDE2LWJpdCBpbnRlZ2VyIHRvIHN0cmluZyBmb3IgdGhlIGxlYWYgaWQgdW5k ZXINCiAgICA+ICAgICAgICJxb3MtY2xhc3NpZmljYXRpb24tcG9saWN5IiBjb250YWluZXIuDQog ICAgPiANCiAgICA+ICAgIG8gIFN0aWNrIHRvIHVzaW5nIG9yZGVyZWQtYnkgdXNlciBhbmQgcmVt b3ZlIGluZWZmaWNpZW5jeSB0byBtYXANCiAgICA+ICAgICAgIHNlcnZpY2UgbW9kZWwgc2VxdWVu Y2UgbnVtYmVyIHRvIGRldmljZSBtb2RlbCBzZXF1ZW5jZSBudW1iZXIuDQogICAgPiANCiAgICA+ ICAgIG8gIFJlbW92ZSBtYW5kYXRpbmcgdGhlIHVzZSBvZiBkZXZpYXRpb25zIGFuZCBhZGQgImlm LWZlYXR1cmUgdGFyZ2V0LQ0KICAgID4gICAgICAgc2l0ZXMiIHVuZGVyIHRoZSBsZWFmLWxpc3Qg dGFyZ2V0LXNpdGVzIGluIHNlY3Rpb24gNS4xMC4yLg0KICAgID4gDQogICAgPiAgICBvICBSRkMy MTE5IGxhbmd1YWdlIGNoYW5nZXMgb24gb3BlcmF0aW9uIG9mIHRoZSBtYW5hZ2VtZW50IHN5c3Rl bSBpbg0KICAgID4gICAgICAgU2VjdGlvbiA1LjYsM3JkIHBhcmFncmFwaCBhbmQgc2VjdGlvbiA3 Lg0KICAgID4gDQogICAgPiAgICBvICBGaXggaW5jb21wbGV0ZSBkZXNjcmlwdGlvbiBzdGF0ZW1l bnRzLg0KICAgID4gDQogICAgPiAgICBvICBDaGFuZ2UgdGhlIHVzZSBvZiB0aGUgYWJzb2x1dGUg cGF0aHMgdG8gdGhlIHVzZSBvZiByZWxhdGl2ZSBwYXRocw0KICAgID4gICAgICAgaW4gdGhlICJt dXN0IiBzdGF0ZW1lbnQgb3IgInBhdGgiIHN0YXRlbWVudCBmb3IgdnBuLXBvbGljeS1pZCBsZWFm DQogICAgPiAgICAgICBub2RlLCBtYW5hZ2VtZW50IGNvbnRhaW5lciwgbG9jYXRpb24gbGVhZiBu b2RlLCBkZXZpY2VzIGNvbnRhaW5lciwNCiAgICA+ICAgICAgIGxvY2F0aW9uIGNhc2UsIGxvY2F0 aW9uLXJlZmVyZW5jZSBsZWFmLCBkZXZpY2UgY2FzZSwgZGV2aWNlLQ0KICAgID4gICAgICAgcmVm ZXJlbmNlIGxlYWYgdG8gbWFrZSBjb25maWd1cmF0aW9uIGlzIG9ubHkgYXBwbGljYWJsZSB0byB0 aGUNCiAgICA+ICAgICAgIGN1cnJlbnQgc2l0ZXMuDQogICAgPiANCiAgICA+ICAgIG8gIENoYW5n ZSAibXVzdCIgc3RhdGVtZW50IHRvICJ3aGVuIiBzdGF0ZW1lbnQgZm9yIG1hbmFnZW1lbnQNCiAg ICA+ICAgICAgIGNvbnRhaW5lciBkZXZpY2UgY29udGFpbmVyLg0KICAgID4gDQogICAgPiAgICBv ICBEZWZpbmUgbmV3IGdyb3VwaW5nIHZwbi1wcm9maWxlLWNmZyBmb3IgYWxsIHRoZSBpZGVudGlm aWVycw0KICAgID4gICAgICAgcHJvdmlkZWQgYnkgU1AgdG8gdGhlIGN1c3RvbWVyLiAgVGhlIGlk ZW50aWZpZXJzIGluY2x1ZGUgY2xvdWQtDQogICAgPiAgICAgICBpZGVudGlmaWVyLCBzdGQtcW9z LXByb2ZpbGUuDQogICAgPiANCiAgICA+ICAgIG8gIEFkZCBpbiB0aGUgWFBBVEggc3RyaW5nIHJl cHJlc2VudGF0aW9uIGFuZCByZW1vdmUgdW5xdWFsaWZpZWQNCiAgICA+ICAgICAgIG5hbWUuDQog ICAgPiANCiAgICA+ICAgIG8gIFJlbW92ZSByZWR1bmRhbnQgcGFyYW1ldGVycyBpbiB0aGUgY2xv dWQgYWNjZXNzLg0KICAgID4gDQogICAgPiAgICBvICBBZGQgYSBmZXcgdGV4dCB0byBjbGFyaWZ5 IHdoYXQgdGhlIHNpdGUgaXMgaW4gc2VjdGlvbiA2LjMuDQogICAgPiANCiAgICA+ICAgIG8gIEFk ZCBtdWx0aS1maWx0ZXIgYW5kIG11bHRpLVZQTiBwZXIgZW50cnkgc3VwcG9ydCBmb3IgVlBOIHBv bGljeS4NCiAgICA+IA0KICAgID4gICAgbyAgTW9kaWZ5IGRlc2NyaXB0aW9uIGZvciBzdmMtYmFu ZHdpZHRoIGxlYWYgdG8gbWFrZSBpdCBjb25zaXN0ZW50DQogICAgPiAgICAgICB3aXRoIHRoZSB0 ZXh0IGluIHNlY3Rpb24gNS4xMC4xLg0KICAgID4gDQogICAgPiAgICBvICBBZGQgdGV4dCB0byBj bGFyaWZ5IHRoZSB3YXkgdG8gYWNoaWV2ZSBQZXItVlBOIFFvUyBwb2xpY3kuDQogICAgPiANCiAg ICA+ICAgIG8gIENoYW5nZSBndWFyYW50ZWVkLWJ3LXBlcmNlbnQgZGF0YSB0eXBlIGZyb20gdWlu dDggdG8gZGVjaW1hbDY0Lg0KICAgID4gDQogICAgPiANCiAgICA+IFJldmlld3MgYW5kIENvbW1l bnRzIGFyZSBhbHdheXMgd2VsY29tZS4NCiAgICA+IA0KICAgID4gQmVzdCBSZWdhcmRzLA0KICAg ID4gDQogICAgPiBHaXVzZXBwZQ0KICAgID4gDQogICAgPiAtLS0tLU1lc3NhZ2dpbyBvcmlnaW5h bGUtLS0tLQ0KICAgID4gRGE6IEwyc20gW21haWx0bzpsMnNtLWJvdW5jZXNAaWV0Zi5vcmddIFBl ciBjb250byBkaSBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCiAgICA+IEludmlhdG86IG1hcnRl ZMOsIDE2IGdlbm5haW8gMjAxOCAxMDo0Ng0KICAgID4gQTogaS1kLWFubm91bmNlQGlldGYub3Jn DQogICAgPiBDYzogbDJzbUBpZXRmLm9yZw0KICAgID4gT2dnZXR0bzogW0wyc21dIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLTA1LnR4dA0KICAgID4gDQog ICAgPiANCiAgICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0cw0KICAgIGRpcmVjdG9yaWVzLg0KICAgID4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTDJWUE4gU2VydmljZSBNb2RlbCBXRyBvZiB0aGUgSUVU Ri4NCiAgICA+IA0KICAgID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBBIFlBTkcgRGF0YSBN b2RlbCBmb3IgTDJWUE4gU2VydmljZSBEZWxpdmVyeQ0KICAgID4gICAgICAgICBBdXRob3JzICAg ICAgICAgOiBCaW4gV2VuDQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEdpdXNlcHBl IEZpb2Njb2xhDQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgIENob25nZmVuZyBYaWUN CiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTHVheSBKYWxpbA0KICAgID4gCUZpbGVu YW1lICAgICAgICA6IGRyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLTA1LnR4dA0K ICAgID4gCVBhZ2VzICAgICAgICAgICA6IDE0OQ0KICAgID4gCURhdGUgICAgICAgICAgICA6IDIw MTgtMDEtMTYNCiAgICA+IA0KICAgID4gQWJzdHJhY3Q6DQogICAgPiAgICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgdGhhdCBjYW4gYmUgdXNlZCB0byBjb25maWd1cmUN CiAgICA+ICAgIGEgTGF5ZXIgMiBQcm92aWRlciBQcm92aXNpb25lZCBWUE4gc2VydmljZS4NCiAg ICA+IA0KICAgID4gICAgVGhpcyBtb2RlbCBpcyBpbnRlbmRlZCB0byBiZSBpbnN0YW50aWF0ZWQg YXQgbWFuYWdlbWVudCBzeXN0ZW0gdG8NCiAgICA+ICAgIGRlbGl2ZXIgdGhlIG92ZXJhbGwgc2Vy dmljZS4gIFRoaXMgbW9kZWwgaXMgbm90IGEgY29uZmlndXJhdGlvbiBtb2RlbA0KICAgID4gICAg dG8gYmUgdXNlZCBkaXJlY3RseSBvbiBuZXR3b3JrIGVsZW1lbnRzLCBidXQgcHJvdmlkZXMgYW4g YWJzdHJhY3RlZA0KICAgID4gICAgdmlldyBvZiB0aGUgTGF5ZXIgMiBWUE4gc2VydmljZSBjb25m aWd1cmF0aW9uIGNvbXBvbmVudHMuICBJdCBpcyB1cA0KICAgID4gICAgdG8gYSBtYW5hZ2VtZW50 IHN5c3RlbSB0byB0YWtlIHRoaXMgYXMgYW4gaW5wdXQgYW5kIGdlbmVyYXRlIHNwZWNpZmljDQog ICAgPiAgICBjb25maWd1cmF0aW9ucyBtb2RlbHMgdG8gY29uZmlndXJlIHRoZSBkaWZmZXJlbnQg bmV0d29yayBlbGVtZW50cyB0bw0KICAgID4gICAgZGVsaXZlciB0aGUgc2VydmljZS4gIEhvdyBj b25maWd1cmF0aW9uIG9mIG5ldHdvcmsgZWxlbWVudHMgaXMgZG9uZQ0KICAgID4gICAgaXMgb3V0 IG9mIHNjb3BlIG9mIHRoZSBkb2N1bWVudC4NCiAgICA+IA0KICAgID4gICAgVGhlIGRhdGEgbW9k ZWwgaW4gdGhpcyBkb2N1bWVudCBpbmNsdWRlcyBzdXBwb3J0IGZvciBwb2ludC10by1wb2ludA0K ICAgID4gICAgVmlydHVhbCBQcml2YXRlIFdpcmUgU2VydmljZXMgKFZQV1MpIGFuZCBtdWx0aXBv aW50IFZpcnR1YWwgUHJpdmF0ZQ0KICAgID4gICAgTEFOIHNlcnZpY2VzIChWUExTKSB0aGF0IHVz ZSBQc2V1ZG93aXJlcyBzaWduYWxlZCB1c2luZyB0aGUgTGFiZWwNCiAgICA+ICAgIERpc3RyaWJ1 dGlvbiBQcm90b2NvbCAoTERQKSBhbmQgdGhlIEJvcmRlciBHYXRld2F5IFByb3RvY29sIChCR1Ap IGFzDQogICAgPiAgICBkZXNjcmliZWQgaW4gUkZDNDc2MSBhbmQgUkZDNjYyNC4NCiAgICA+IA0K ICAgID4gDQogICAgPiANCiAgICA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv ciB0aGlzIGRyYWZ0IGlzOg0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwvDQogICAgPiANCiAgICA+IFRoZXJl IGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICA+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC0w NQ0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC0wNQ0KICAgID4gDQogICAgPiBBIGRpZmYgZnJvbSB0 aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAgPiBodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwt MDUNCiAgICA+IA0KICAgID4gDQogICAgPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgPiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KICAgID4gDQogICAgPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KICAgID4gTDJzbSBtYWlsaW5nIGxpc3QNCiAgICA+IEwyc21AaWV0Zi5v cmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDJzbQ0KICAg ID4gDQogICAgPiBRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJp enphdGkgZXNjbHVzaXZhbWVudGUgYWxsZQ0KICAgIHBlcnNvbmUNCiAgICA+IGluZGljYXRlLiBM YSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRh bGxhDQogICAgY29ub3NjZW56YSBkaQ0KICAgID4gcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJp Z29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvDQogICAgPiBxdWVz dG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFy bmUgaW1tZWRpYXRhDQogICAgPiBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZl ZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KICAgID4gDQogICAgPiBUaGlzIGUt bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4g cHJpdmlsZWdlZA0KICAgID4gaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUo cykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywNCiAgICBwcmludGluZw0KICAgID4gb3Ig dXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsDQogICAgPiBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg YW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4NCiAgICA+IGUt bWFpbCwgVGhhbmtzLg0KICAgID4gDQogICAgPiBSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3Rh bXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQogICAgPiANCiAgICA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBMMnNt IG1haWxpbmcgbGlzdA0KICAgID4gTDJzbUBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sMnNtDQogICAgDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBMMnNtIG1haWxpbmcgbGlzdA0KICAg IEwyc21AaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2wyc20NCiAgICANCg0K From nobody Mon Jan 22 08:46:17 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6D4124B18; Mon, 22 Jan 2018 08:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYtT-D1mj3V5; Mon, 22 Jan 2018 08:46:14 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2311C124207; Mon, 22 Jan 2018 08:46:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8834; q=dns/txt; s=iport; t=1516639573; x=1517849173; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=SMQEEMI3jYOZ+v4pJbhMd6eDrjaukTFQmgpq83/Zwxs=; b=nAorv3PT5x3f30hCrv+ElhN6cbe/i3yMZF88RYFdEo+Chv630LFkqPWL GBwskM6J6FHqwZOaP77W77Fzk6z2I2OYUwuU1yWlzk2wuySKsjdUWp3Mm 2IBVr1yHCxXdcTaeSVxe3zbpEKxIvVRMv1M6Kh93RmO+hLopGPCoweZlP E=; X-IronPort-AV: E=Sophos;i="5.46,397,1511827200"; d="scan'208";a="1589033" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2018 16:46:11 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0MGkBUB021678; Mon, 22 Jan 2018 16:46:11 GMT To: "Roque Gagliano (rogaglia)" , "adrian@olddog.co.uk" Cc: "draft-ietf-l2sm-l2vpn-service-model@ietf.org" , "l2sm@ietf.org" , "l2sm-chairs@ietf.org" References: <058701d38f71$d52d2b60$7f878220$@olddog.co.uk> <47CEAC7E-BCD8-4B93-BB2A-2EFACDD55223@cisco.com> From: Benoit Claise Message-ID: <7381e8c5-9481-62b7-f11f-f0dc0bfcae0c@cisco.com> Date: Mon, 22 Jan 2018 17:46:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <47CEAC7E-BCD8-4B93-BB2A-2EFACDD55223@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [L2sm] Next steps with draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 16:46:16 -0000 Hi Roque, While I understand the willingness to understand the big picture, I don't believe it's appropriate for an IETF document to describe what is happening in different efforts in the industry. Regards, Benoit > Hi Adrian, > > One point that I would like to raise is that it would be important to describe the relationship between this work and what is happening at other standardization bodies such as the MEF Legato YANG service modules and the TAPI work at the ONF. > > Regards, > Roque > > Ref MEF Legato YANG modules: https://github.com/MEF-GIT/YANG-public/tree/master/src/model/draft > > > On 17/01/18 10:02, "L2sm on behalf of Adrian Farrel" wrote: > > All, > > We're approaching Working Groups last call on our draft. > > - I have requested a YANG Doctor review of the current revision > - I plan to do an English language review at the same time (unless > someone else want to volunteer) > - NOW is the time for you to do your technical review. Don't leave > is until WG last call! > - All things being equal, we will have WG last call in early February > > Thanks, > > Adrian > > > -----Original Message----- > > From: L2sm [mailto:l2sm-bounces@ietf.org] On Behalf Of Fioccola Giuseppe > > Sent: 16 January 2018 10:05 > > To: l2sm@ietf.org > > Cc: draft-ietf-l2sm-l2vpn-service-model@ietf.org; l2sm-chairs@ietf.org > > Subject: [L2sm] I: I-D Action: draft-ietf-l2sm-l2vpn-service-model-05.txt > > > > Hi All, > > This is the new version of the draft-ietf-l2sm-l2vpn-service-model. > > It addresses some comments from people that are trying to implement the draft > > and it includes also an update to the references in particular to RFC8199 and > > RFC8309. > > As usual, the fundamental changes are summarized in the Appendix A "Changes > > Log": > > > > Changes in v-(05) include: > > > > o Change type from 16-bit integer to string for the leaf id under > > "qos-classification-policy" container. > > > > o Stick to using ordered-by user and remove inefficiency to map > > service model sequence number to device model sequence number. > > > > o Remove mandating the use of deviations and add "if-feature target- > > sites" under the leaf-list target-sites in section 5.10.2. > > > > o RFC2119 language changes on operation of the management system in > > Section 5.6,3rd paragraph and section 7. > > > > o Fix incomplete description statements. > > > > o Change the use of the absolute paths to the use of relative paths > > in the "must" statement or "path" statement for vpn-policy-id leaf > > node, management container, location leaf node, devices container, > > location case, location-reference leaf, device case, device- > > reference leaf to make configuration is only applicable to the > > current sites. > > > > o Change "must" statement to "when" statement for management > > container device container. > > > > o Define new grouping vpn-profile-cfg for all the identifiers > > provided by SP to the customer. The identifiers include cloud- > > identifier, std-qos-profile. > > > > o Add in the XPATH string representation and remove unqualified > > name. > > > > o Remove redundant parameters in the cloud access. > > > > o Add a few text to clarify what the site is in section 6.3. > > > > o Add multi-filter and multi-VPN per entry support for VPN policy. > > > > o Modify description for svc-bandwidth leaf to make it consistent > > with the text in section 5.10.1. > > > > o Add text to clarify the way to achieve Per-VPN QoS policy. > > > > o Change guaranteed-bw-percent data type from uint8 to decimal64. > > > > > > Reviews and Comments are always welcome. > > > > Best Regards, > > > > Giuseppe > > > > -----Messaggio originale----- > > Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di internet-drafts@ietf.org > > Inviato: martedì 16 gennaio 2018 10:46 > > A: i-d-announce@ietf.org > > Cc: l2sm@ietf.org > > Oggetto: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-05.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the L2VPN Service Model WG of the IETF. > > > > Title : A YANG Data Model for L2VPN Service Delivery > > Authors : Bin Wen > > Giuseppe Fioccola > > Chongfeng Xie > > Luay Jalil > > Filename : draft-ietf-l2sm-l2vpn-service-model-05.txt > > Pages : 149 > > Date : 2018-01-16 > > > > Abstract: > > This document defines a YANG data model that can be used to configure > > a Layer 2 Provider Provisioned VPN service. > > > > This model is intended to be instantiated at management system to > > deliver the overall service. This model is not a configuration model > > to be used directly on network elements, but provides an abstracted > > view of the Layer 2 VPN service configuration components. It is up > > to a management system to take this as an input and generate specific > > configurations models to configure the different network elements to > > deliver the service. How configuration of network elements is done > > is out of scope of the document. > > > > The data model in this document includes support for point-to-point > > Virtual Private Wire Services (VPWS) and multipoint Virtual Private > > LAN services (VPLS) that use Pseudowires signaled using the Label > > Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as > > described in RFC4761 and RFC6624. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-05 > > https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-05 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-l2sm-l2vpn-service-model-05 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > L2sm mailing list > > L2sm@ietf.org > > https://www.ietf.org/mailman/listinfo/l2sm > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone > > indicate. La diffusione, copia o qualsiasi altra azione derivante dalla > conoscenza di > > queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto > > questo documento per errore siete cortesemente pregati di darne immediata > > comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may contain privileged > > information intended for the addressee(s) only. Dissemination, copying, > printing > > or use by anybody else is unauthorised. If you are not the intended recipient, > > please delete this message and any attachments and advise the sender by return > > e-mail, Thanks. > > > > Rispetta l'ambiente. Non stampare questa mail se non è necessario. > > > > _______________________________________________ > > L2sm mailing list > > L2sm@ietf.org > > https://www.ietf.org/mailman/listinfo/l2sm > > _______________________________________________ > L2sm mailing list > L2sm@ietf.org > https://www.ietf.org/mailman/listinfo/l2sm > > From nobody Mon Jan 22 10:13:00 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F33129516; Mon, 22 Jan 2018 10:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q5RO0VdYwt7; Mon, 22 Jan 2018 10:12:56 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 57BF91289B0; Mon, 22 Jan 2018 10:12:56 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id p36so8295011otd.10; Mon, 22 Jan 2018 10:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8cFxjHnaQ0eGyfciODOuMJfgGw/VdHYEiijiaeoyEus=; b=IxRxH3Na0ZgE6uQGrhV/Q0Jp8zP1O0Vn2Ev64cIXSI0A4DbzB4SMHOKwC1zFfx6MZq dJmPHrv+iTf7URA+xs3OLyv1oi0v9jePfqzwjgpWfUnfcjriUeaJzd7+gD1G9HwR3ACm X5I0AX0mcsP8l+NFOJqSpH/Wa+1nIC6BKz48jUj+uO6qKRhm6Ej4M4zx/mwWn4Y4ay2z Jqj1usTXXATQnsPB6IaSA+BAF0LAYNPX4EdEpvRlj5X5pZkowuCAgEkkkI+J3X001RmW YZRQQTe7B4pKI2MFVOIGRZ/h/6T/XQlFSycwhcHEfkJ004hiyKVx+UchwrxUDSUUKMy0 tVZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8cFxjHnaQ0eGyfciODOuMJfgGw/VdHYEiijiaeoyEus=; b=CbSQw/tsQezwdCxoOuQfK0m39H4s270s/n74wRWkfU/rRa5ZwpxQf4CZ7JEuhB2z+G EdvjXaE6fJHALL0jEbrNUXHNUsN1bphPPJNpMJziUZWfthhtndrQcwMmJEwYq58LeoCt zO40OF4JeJSRi31h/M/PVc78MGI4yzOhJ43kusYVfrwo8P4vJ6pML1MlDA60B7IpXQo2 KPn24yJDW3BifqC2Q+m1IeDwjdFFv9KyYxiUeAuuqZdfBGPwOBQrZh2NaAHHTznpfAEK jTFj1fvEn3CKVs6SonFKsJAQyuuAueJ7Ls4HKFmS1TvBXYNJTx43Ud1M0fbER0C3kU0F P3NQ== X-Gm-Message-State: AKwxyte9aMSbhF26AQ9cL+6M3Ll9DdbHMRrct/msXJn0mLuf/Nypy2Xq SYyVLcKQxWZkT8KVYVdr8OsQZDkIwRmLhsRbnWE= X-Google-Smtp-Source: AH8x2259mDEUaS08ZzHEBSZkey7ACsXLvYlm1eg5Fw+NA60T44SNH4AKiq7k5NrUqAZ2iaf6Kgz+DXe5SxJKDucSVmE= X-Received: by 10.157.15.97 with SMTP id 88mr1814947ott.223.1516644775656; Mon, 22 Jan 2018 10:12:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.27.211 with HTTP; Mon, 22 Jan 2018 10:12:35 -0800 (PST) In-Reply-To: <7381e8c5-9481-62b7-f11f-f0dc0bfcae0c@cisco.com> References: <058701d38f71$d52d2b60$7f878220$@olddog.co.uk> <47CEAC7E-BCD8-4B93-BB2A-2EFACDD55223@cisco.com> <7381e8c5-9481-62b7-f11f-f0dc0bfcae0c@cisco.com> From: "Andrew G. Malis" Date: Mon, 22 Jan 2018 13:12:35 -0500 Message-ID: To: Benoit Claise Cc: "Roque Gagliano (rogaglia)" , "adrian@olddog.co.uk" , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" , "l2sm-chairs@ietf.org" , "l2sm@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c04c9a81a81570563616146" Archived-At: Subject: Re: [L2sm] Next steps with draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 18:12:59 -0000 --94eb2c04c9a81a81570563616146 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Benoit, We do that all the time. A recent example is draft-ietf-lpwan-overview. Cheers, Andy On Mon, Jan 22, 2018 at 11:46 AM, Benoit Claise wrote: > Hi Roque, > > While I understand the willingness to understand the big picture, I don't > believe it's appropriate for an IETF document to describe what is happeni= ng > in different efforts in the industry. > > Regards, Benoit > > Hi Adrian, >> >> One point that I would like to raise is that it would be important to >> describe the relationship between this work and what is happening at oth= er >> standardization bodies such as the MEF Legato YANG service modules and t= he >> TAPI work at the ONF. >> >> Regards, >> Roque >> >> Ref MEF Legato YANG modules: https://github.com/MEF-GIT/YAN >> G-public/tree/master/src/model/draft >> >> >> On 17/01/18 10:02, "L2sm on behalf of Adrian Farrel" < >> l2sm-bounces@ietf.org on behalf of adrian@olddog.co.uk> wrote: >> >> All, >> We're approaching Working Groups last call on our draft. >> - I have requested a YANG Doctor review of the current revisio= n >> - I plan to do an English language review at the same time (unless >> someone else want to volunteer) >> - NOW is the time for you to do your technical review. Don't leave >> is until WG last call! >> - All things being equal, we will have WG last call in early Februa= ry >> Thanks, >> Adrian >> > -----Original Message----- >> > From: L2sm [mailto:l2sm-bounces@ietf.org] On Behalf Of Fioccola >> Giuseppe >> > Sent: 16 January 2018 10:05 >> > To: l2sm@ietf.org >> > Cc: draft-ietf-l2sm-l2vpn-service-model@ietf.org; >> l2sm-chairs@ietf.org >> > Subject: [L2sm] I: I-D Action: draft-ietf-l2sm-l2vpn-service- >> model-05.txt >> > >> > Hi All, >> > This is the new version of the draft-ietf-l2sm-l2vpn-service- >> model. >> > It addresses some comments from people that are trying to >> implement the draft >> > and it includes also an update to the references in particular to >> RFC8199 and >> > RFC8309. >> > As usual, the fundamental changes are summarized in the Appendix = A >> "Changes >> > Log": >> > >> > Changes in v-(05) include: >> > >> > o Change type from 16-bit integer to string for the leaf id >> under >> > "qos-classification-policy" container. >> > >> > o Stick to using ordered-by user and remove inefficiency to m= ap >> > service model sequence number to device model sequence >> number. >> > >> > o Remove mandating the use of deviations and add "if-feature >> target- >> > sites" under the leaf-list target-sites in section 5.10.2. >> > >> > o RFC2119 language changes on operation of the management >> system in >> > Section 5.6,3rd paragraph and section 7. >> > >> > o Fix incomplete description statements. >> > >> > o Change the use of the absolute paths to the use of relative >> paths >> > in the "must" statement or "path" statement for >> vpn-policy-id leaf >> > node, management container, location leaf node, devices >> container, >> > location case, location-reference leaf, device case, device= - >> > reference leaf to make configuration is only applicable to >> the >> > current sites. >> > >> > o Change "must" statement to "when" statement for management >> > container device container. >> > >> > o Define new grouping vpn-profile-cfg for all the identifiers >> > provided by SP to the customer. The identifiers include >> cloud- >> > identifier, std-qos-profile. >> > >> > o Add in the XPATH string representation and remove unqualifi= ed >> > name. >> > >> > o Remove redundant parameters in the cloud access. >> > >> > o Add a few text to clarify what the site is in section 6.3. >> > >> > o Add multi-filter and multi-VPN per entry support for VPN >> policy. >> > >> > o Modify description for svc-bandwidth leaf to make it >> consistent >> > with the text in section 5.10.1. >> > >> > o Add text to clarify the way to achieve Per-VPN QoS policy. >> > >> > o Change guaranteed-bw-percent data type from uint8 to >> decimal64. >> > >> > >> > Reviews and Comments are always welcome. >> > >> > Best Regards, >> > >> > Giuseppe >> > >> > -----Messaggio originale----- >> > Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di >> internet-drafts@ietf.org >> > Inviato: marted=C3=AC 16 gennaio 2018 10:46 >> > A: i-d-announce@ietf.org >> > Cc: l2sm@ietf.org >> > Oggetto: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service- >> model-05.txt >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Draft= s >> directories. >> > This draft is a work item of the L2VPN Service Model WG of the >> IETF. >> > >> > Title : A YANG Data Model for L2VPN Service >> Delivery >> > Authors : Bin Wen >> > Giuseppe Fioccola >> > Chongfeng Xie >> > Luay Jalil >> > Filename : draft-ietf-l2sm-l2vpn-service-model-05.txt >> > Pages : 149 >> > Date : 2018-01-16 >> > >> > Abstract: >> > This document defines a YANG data model that can be used to >> configure >> > a Layer 2 Provider Provisioned VPN service. >> > >> > This model is intended to be instantiated at management system >> to >> > deliver the overall service. This model is not a configuratio= n >> model >> > to be used directly on network elements, but provides an >> abstracted >> > view of the Layer 2 VPN service configuration components. It >> is up >> > to a management system to take this as an input and generate >> specific >> > configurations models to configure the different network >> elements to >> > deliver the service. How configuration of network elements is >> done >> > is out of scope of the document. >> > >> > The data model in this document includes support for >> point-to-point >> > Virtual Private Wire Services (VPWS) and multipoint Virtual >> Private >> > LAN services (VPLS) that use Pseudowires signaled using the >> Label >> > Distribution Protocol (LDP) and the Border Gateway Protocol >> (BGP) as >> > described in RFC4761 and RFC6624. >> > >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-servi >> ce-model/ >> > >> > There are also htmlized versions available at: >> > https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-0= 5 >> > https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn- >> service-model-05 >> > >> > A diff from the previous version is available at: >> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2sm-l2vpn-serv >> ice-model-05 >> > >> > >> > Please note that it may take a couple of minutes from the time of >> submission >> > until the htmlized version and diff are available at >> tools.ietf.org. >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > L2sm mailing list >> > L2sm@ietf.org >> > https://www.ietf.org/mailman/listinfo/l2sm >> > >> > Questo messaggio e i suoi allegati sono indirizzati esclusivament= e >> alle >> persone >> > indicate. La diffusione, copia o qualsiasi altra azione derivante >> dalla >> conoscenza di >> > queste informazioni sono rigorosamente vietate. Qualora abbiate >> ricevuto >> > questo documento per errore siete cortesemente pregati di darne >> immediata >> > comunicazione al mittente e di provvedere alla sua distruzione, >> Grazie. >> > >> > This e-mail and any attachments is confidential and may contain >> privileged >> > information intended for the addressee(s) only. Dissemination, >> copying, >> printing >> > or use by anybody else is unauthorised. If you are not the >> intended recipient, >> > please delete this message and any attachments and advise the >> sender by return >> > e-mail, Thanks. >> > >> > Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 neces= sario. >> > >> > _______________________________________________ >> > L2sm mailing list >> > L2sm@ietf.org >> > https://www.ietf.org/mailman/listinfo/l2sm >> _______________________________________________ >> L2sm mailing list >> L2sm@ietf.org >> https://www.ietf.org/mailman/listinfo/l2sm >> >> > > _______________________________________________ > L2sm mailing list > L2sm@ietf.org > https://www.ietf.org/mailman/listinfo/l2sm > --94eb2c04c9a81a81570563616146 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Benoit,

We do that all the time. A rece= nt example is draft-ietf-lpwan-overview.

Cheers,=
Andy


On Mon, Jan 22, 2018 at 11:46 AM, Benoit Claise <= bclaise@cisco.com> wrote:
H= i Roque,

While I understand the willingness to understand the big picture, I don'= ;t believe it's appropriate for an IETF document to describe what is ha= ppening in different efforts in the industry.

Regards, Benoit

Hi Adrian,

One point that I would like to raise is that it would be important to descr= ibe the relationship between this work and what is happening at other stand= ardization bodies such as the MEF Legato YANG service modules and the TAPI = work at the ONF.

Regards,
Roque

Ref MEF Legato YANG modules: https= ://github.com/MEF-GIT/YANG-public/tree/master/src/model/draft=


On 17/01/18 10:02, "L2sm on behalf of Adrian Farrel" <l2sm-bounces@ietf.org on behalf of ad= rian@olddog.co.uk> wrote:

=C2=A0 =C2=A0 =C2=A0All,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We're approaching Working Groups las= t call on our draft.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - I have requested a YANG Doctor review = of the current revision
=C2=A0 =C2=A0 =C2=A0- I plan to do an English language review at the same t= ime (unless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 someone else want to volunteer)
=C2=A0 =C2=A0 =C2=A0- NOW is the time for you to do your technical review. = Don't leave
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is until WG last call!
=C2=A0 =C2=A0 =C2=A0- All things being equal, we will have WG last call in = early February
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adrian
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 =C2=A0> From: L2sm [mailto:l2sm-bounces@ietf.org] On Behalf Of Fioccol= a Giuseppe
=C2=A0 =C2=A0 =C2=A0> Sent: 16 January 2018 10:05
=C2=A0 =C2=A0 =C2=A0> To: l2sm@ietf.org
=C2=A0 =C2=A0 =C2=A0> Cc: draft-ietf-l2sm-l2vpn-service-mode= l@ietf.org; l= 2sm-chairs@ietf.org
=C2=A0 =C2=A0 =C2=A0> Subject: [L2sm] I: I-D Action: draft-ietf-l2sm-l2v= pn-service-model-05.txt
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Hi All,
=C2=A0 =C2=A0 =C2=A0> This is the new version of the draft-ietf-l2sm-l2v= pn-service-model.
=C2=A0 =C2=A0 =C2=A0> It addresses some comments from people that are tr= ying to implement the draft
=C2=A0 =C2=A0 =C2=A0> and it includes also an update to the references i= n particular to RFC8199 and
=C2=A0 =C2=A0 =C2=A0> RFC8309.
=C2=A0 =C2=A0 =C2=A0> As usual, the fundamental changes are summarized i= n the Appendix A "Changes
=C2=A0 =C2=A0 =C2=A0> Log":
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Changes in v-(05) include:
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Change type from 16-bit integ= er to string for the leaf id under
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0"qos-classification= -policy" container.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Stick to using ordered-by use= r and remove inefficiency to map
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0service model sequence n= umber to device model sequence number.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Remove mandating the use of d= eviations and add "if-feature target-
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0sites" under the le= af-list target-sites in section 5.10.2.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 RFC2119 language changes on o= peration of the management system in
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.6,3rd paragrap= h and section 7.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Fix incomplete description st= atements.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Change the use of the absolut= e paths to the use of relative paths
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in the "must" = statement or "path" statement for vpn-policy-id leaf
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0node, management contain= er, location leaf node, devices container,
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0location case, location-= reference leaf, device case, device-
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0reference leaf to make c= onfiguration is only applicable to the
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0current sites.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Change "must" state= ment to "when" statement for management
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0container device contain= er.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Define new grouping vpn-profi= le-cfg for all the identifiers
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0provided by SP to the cu= stomer.=C2=A0 The identifiers include cloud-
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0identifier, std-qos-prof= ile.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Add in the XPATH string repre= sentation and remove unqualified
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0name.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Remove redundant parameters i= n the cloud access.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Add a few text to clarify wha= t the site is in section 6.3.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Add multi-filter and multi-VP= N per entry support for VPN policy.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Modify description for svc-ba= ndwidth leaf to make it consistent
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with the text in section= 5.10.1.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Add text to clarify the way t= o achieve Per-VPN QoS policy.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Change guaranteed-bw-percent = data type from uint8 to decimal64.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Reviews and Comments are always welcome.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Best Regards,
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Giuseppe
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> -----Messaggio originale-----
=C2=A0 =C2=A0 =C2=A0> Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di internet-drafts@ietf= .org
=C2=A0 =C2=A0 =C2=A0> Inviato: marted=C3=AC 16 gennaio 2018 10:46
=C2=A0 =C2=A0 =C2=A0> A: i-d-announce@ietf.org
=C2=A0 =C2=A0 =C2=A0> Cc: l2sm@ietf.org
=C2=A0 =C2=A0 =C2=A0> Oggetto: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-= service-model-05.txt
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> A New Internet-Draft is available from the on-line= Internet-Drafts
=C2=A0 =C2=A0 =C2=A0directories.
=C2=A0 =C2=A0 =C2=A0> This draft is a work item of the L2VPN Service Mod= el WG of the IETF.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A YANG Data Model for L2VPN Service Delive= ry
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: Bin Wen
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Giuseppe Fioccola
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Chongfeng Xie
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Luay Jalil
=C2=A0 =C2=A0 =C2=A0>=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-l2sm-l2vpn-service-model-05.txt
=C2=A0 =C2=A0 =C2=A0>=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 149
=C2=A0 =C2=A0 =C2=A0>=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-01-16
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Abstract:
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 This document defines a YANG data mod= el that can be used to configure
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 a Layer 2 Provider Provisioned VPN se= rvice.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 This model is intended to be instanti= ated at management system to
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 deliver the overall service.=C2=A0 Th= is model is not a configuration model
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 to be used directly on network elemen= ts, but provides an abstracted
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 view of the Layer 2 VPN service confi= guration components.=C2=A0 It is up
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 to a management system to take this a= s an input and generate specific
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 configurations models to configure th= e different network elements to
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 deliver the service.=C2=A0 How config= uration of network elements is done
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 is out of scope of the document.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 The data model in this document inclu= des support for point-to-point
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Virtual Private Wire Services (VPWS) = and multipoint Virtual Private
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 LAN services (VPLS) that use Pseudowi= res signaled using the Label
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Distribution Protocol (LDP) and the B= order Gateway Protocol (BGP) as
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 described in RFC4761 and RFC6624.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> The IETF datatracker status page for this draft is= :
=C2=A0 =C2=A0 =C2=A0> https:= //datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> There are also htmlized versions available at:
=C2=A0 =C2=A0 =C2=A0> https://t= ools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-05
=C2=A0 =C2=A0 =C2=A0> https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-serv= ice-model-05
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> A diff from the previous version is available at:<= br> =C2=A0 =C2=A0 =C2=A0> h= ttps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2sm-l2vpn-service-= model-05
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Please note that it may take a couple of minutes f= rom the time of submission
=C2=A0 =C2=A0 =C2=A0> until the htmlized version and diff are available = at t= ools.ietf.org.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Internet-Drafts are also available by anonymous FT= P at:
=C2=A0 =C2=A0 =C2=A0> ftp://ftp.ietf.org/internet-drafts/=
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> _____________________________________________= __
=C2=A0 =C2=A0 =C2=A0> L2sm mailing list
=C2=A0 =C2=A0 =C2=A0> L2sm@ietf.org
=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/listinfo/l2sm
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Questo messaggio e i suoi allegati sono indirizzat= i esclusivamente alle
=C2=A0 =C2=A0 =C2=A0persone
=C2=A0 =C2=A0 =C2=A0> indicate. La diffusione, copia o qualsiasi altra a= zione derivante dalla
=C2=A0 =C2=A0 =C2=A0conoscenza di
=C2=A0 =C2=A0 =C2=A0> queste informazioni sono rigorosamente vietate. Qu= alora abbiate ricevuto
=C2=A0 =C2=A0 =C2=A0> questo documento per errore siete cortesemente pre= gati di darne immediata
=C2=A0 =C2=A0 =C2=A0> comunicazione al mittente e di provvedere alla sua= distruzione, Grazie.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> This e-mail and any attachments is confidential an= d may contain privileged
=C2=A0 =C2=A0 =C2=A0> information intended for the addressee(s) only. Di= ssemination, copying,
=C2=A0 =C2=A0 =C2=A0printing
=C2=A0 =C2=A0 =C2=A0> or use by anybody else is unauthorised. If you are= not the intended recipient,
=C2=A0 =C2=A0 =C2=A0> please delete this message and any attachments and= advise the sender by return
=C2=A0 =C2=A0 =C2=A0> e-mail, Thanks.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Rispetta l'ambiente. Non stampare questa mail = se non =C3=A8 necessario.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> _____________________________________________= __
=C2=A0 =C2=A0 =C2=A0> L2sm mailing list
=C2=A0 =C2=A0 =C2=A0> L2sm@ietf.org
=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/listinfo/l2sm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________________________= ____________
=C2=A0 =C2=A0 =C2=A0L2sm mailing list
=C2=A0 =C2=A0 =C2=A0L2sm= @ietf.org
=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/list= info/l2sm
=C2=A0 =C2=A0 =C2=A0

_______________________________________________
L2sm mailing list
L2sm@ietf.org
https://www.ietf.org/mailman/listinfo/l2sm

--94eb2c04c9a81a81570563616146-- From nobody Tue Jan 23 05:02:05 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3728124319; Tue, 23 Jan 2018 05:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l9PJP_N96jt; Tue, 23 Jan 2018 05:02:00 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28A71241F8; Tue, 23 Jan 2018 05:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35077; q=dns/txt; s=iport; t=1516712519; x=1517922119; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=B72CdOAoX1Mp5BgW51OIkLgS/gYUic7u/oZ8y5oHHMI=; b=j7A0X39EkuxdDRUN6VD85cSd6pF4p8rMGlORxgvkdQYSEB9EcOQ0KkES Vq3qfGCd0q5tbbcNVpQIxoDll6Pcu7NL3QQIgposrFQIBXutbCvSS1016 8HEniwM14agbNTNTmKNTnbD80/aAZR+Nso/S3rhUQre8XvV99reNvzjZk E=; X-IronPort-AV: E=Sophos;i="5.46,401,1511827200"; d="scan'208,217";a="1604480" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2018 13:01:57 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0ND1ucJ018507; Tue, 23 Jan 2018 13:01:56 GMT To: "Andrew G. Malis" Cc: "Roque Gagliano (rogaglia)" , "adrian@olddog.co.uk" , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" , "l2sm-chairs@ietf.org" , "l2sm@ietf.org" References: <058701d38f71$d52d2b60$7f878220$@olddog.co.uk> <47CEAC7E-BCD8-4B93-BB2A-2EFACDD55223@cisco.com> <7381e8c5-9481-62b7-f11f-f0dc0bfcae0c@cisco.com> From: Benoit Claise Message-ID: Date: Tue, 23 Jan 2018 14:01:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7FFAA49EC90B43D2A941B579" Content-Language: en-US Archived-At: Subject: Re: [L2sm] Next steps with draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 13:02:04 -0000 This is a multi-part message in MIME format. --------------7FFAA49EC90B43D2A941B579 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Andrew, > Benoit, > > We do that all the time. A recent example is draft-ietf-lpwan-overview. draft-ietf-lpwan-overview is overview type of documents, so that makes sense. In this example, we speak of competing or overlapping efforts. At least some people see it that way. So explaining the relationships between those efforts in a way that will satisfy everybody seems very difficult, if not impossible to me. In those of situations, my view is pragmatic: let the market decide. Regards, Benoit > > Cheers, > Andy > > > On Mon, Jan 22, 2018 at 11:46 AM, Benoit Claise > wrote: > > Hi Roque, > > While I understand the willingness to understand the big picture, > I don't believe it's appropriate for an IETF document to describe > what is happening in different efforts in the industry. > > Regards, Benoit > > Hi Adrian, > > One point that I would like to raise is that it would be > important to describe the relationship between this work and > what is happening at other standardization bodies such as the > MEF Legato YANG service modules and the TAPI work at the ONF. > > Regards, > Roque > > Ref MEF Legato YANG modules: > https://github.com/MEF-GIT/YANG-public/tree/master/src/model/draft > > > > On 17/01/18 10:02, "L2sm on behalf of Adrian Farrel" > on > behalf of adrian@olddog.co.uk > wrote: > >      All, >           We're approaching Working Groups last call on our draft. >           - I have requested a YANG Doctor review of the > current revision >      - I plan to do an English language review at the same > time (unless >         someone else want to volunteer) >      - NOW is the time for you to do your technical review. > Don't leave >         is until WG last call! >      - All things being equal, we will have WG last call in > early February >           Thanks, >           Adrian >           > -----Original Message----- >      > From: L2sm [mailto:l2sm-bounces@ietf.org > ] On Behalf Of Fioccola Giuseppe >      > Sent: 16 January 2018 10:05 >      > To: l2sm@ietf.org >      > Cc: draft-ietf-l2sm-l2vpn-service-model@ietf.org > ; > l2sm-chairs@ietf.org >      > Subject: [L2sm] I: I-D Action: > draft-ietf-l2sm-l2vpn-service-model-05.txt >      > >      > Hi All, >      > This is the new version of the > draft-ietf-l2sm-l2vpn-service-model. >      > It addresses some comments from people that are trying > to implement the draft >      > and it includes also an update to the references in > particular to RFC8199 and >      > RFC8309. >      > As usual, the fundamental changes are summarized in the > Appendix A "Changes >      > Log": >      > >      >    Changes in v-(05) include: >      > >      >    o  Change type from 16-bit integer to string for the > leaf id under >      >       "qos-classification-policy" container. >      > >      >    o  Stick to using ordered-by user and remove > inefficiency to map >      >       service model sequence number to device model > sequence number. >      > >      >    o  Remove mandating the use of deviations and add > "if-feature target- >      >       sites" under the leaf-list target-sites in > section 5.10.2. >      > >      >    o  RFC2119 language changes on operation of the > management system in >      >       Section 5.6,3rd paragraph and section 7. >      > >      >    o  Fix incomplete description statements. >      > >      >    o  Change the use of the absolute paths to the use > of relative paths >      >       in the "must" statement or "path" statement for > vpn-policy-id leaf >      >       node, management container, location leaf node, > devices container, >      >       location case, location-reference leaf, device > case, device- >      >       reference leaf to make configuration is only > applicable to the >      >       current sites. >      > >      >    o  Change "must" statement to "when" statement for > management >      >       container device container. >      > >      >    o  Define new grouping vpn-profile-cfg for all the > identifiers >      >       provided by SP to the customer.  The identifiers > include cloud- >      >       identifier, std-qos-profile. >      > >      >    o  Add in the XPATH string representation and remove > unqualified >      >       name. >      > >      >    o  Remove redundant parameters in the cloud access. >      > >      >    o  Add a few text to clarify what the site is in > section 6.3. >      > >      >    o  Add multi-filter and multi-VPN per entry support > for VPN policy. >      > >      >    o  Modify description for svc-bandwidth leaf to make > it consistent >      >       with the text in section 5.10.1. >      > >      >    o  Add text to clarify the way to achieve Per-VPN > QoS policy. >      > >      >    o  Change guaranteed-bw-percent data type from uint8 > to decimal64. >      > >      > >      > Reviews and Comments are always welcome. >      > >      > Best Regards, >      > >      > Giuseppe >      > >      > -----Messaggio originale----- >      > Da: L2sm [mailto:l2sm-bounces@ietf.org > ] Per conto di > internet-drafts@ietf.org >      > Inviato: martedì 16 gennaio 2018 10:46 >      > A: i-d-announce@ietf.org >      > Cc: l2sm@ietf.org >      > Oggetto: [L2sm] I-D Action: > draft-ietf-l2sm-l2vpn-service-model-05.txt >      > >      > >      > A New Internet-Draft is available from the on-line > Internet-Drafts >      directories. >      > This draft is a work item of the L2VPN Service Model WG > of the IETF. >      > >      >         Title           : A YANG Data Model for L2VPN > Service Delivery >      >         Authors         : Bin Wen >      >                           Giuseppe Fioccola >      >                           Chongfeng Xie >      >                           Luay Jalil >      >  Filename        : > draft-ietf-l2sm-l2vpn-service-model-05.txt >      >  Pages           : 149 >      >  Date            : 2018-01-16 >      > >      > Abstract: >      >    This document defines a YANG data model that can be > used to configure >      >    a Layer 2 Provider Provisioned VPN service. >      > >      >    This model is intended to be instantiated at > management system to >      >    deliver the overall service.  This model is not a > configuration model >      >    to be used directly on network elements, but > provides an abstracted >      >    view of the Layer 2 VPN service configuration > components.  It is up >      >    to a management system to take this as an input and > generate specific >      >    configurations models to configure the different > network elements to >      >    deliver the service.  How configuration of network > elements is done >      >    is out of scope of the document. >      > >      >    The data model in this document includes support for > point-to-point >      >    Virtual Private Wire Services (VPWS) and multipoint > Virtual Private >      >    LAN services (VPLS) that use Pseudowires signaled > using the Label >      >    Distribution Protocol (LDP) and the Border Gateway > Protocol (BGP) as >      >    described in RFC4761 and RFC6624. >      > >      > >      > >      > The IETF datatracker status page for this draft is: >      > > https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ > >      > >      > There are also htmlized versions available at: >      > > https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-05 > >      > > https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-05 > >      > >      > A diff from the previous version is available at: >      > > https://www.ietf.org/rfcdiff?url2=draft-ietf-l2sm-l2vpn-service-model-05 > >      > >      > >      > Please note that it may take a couple of minutes from > the time of submission >      > until the htmlized version and diff are available at > tools.ietf.org . >      > >      > Internet-Drafts are also available by anonymous FTP at: >      > ftp://ftp.ietf.org/internet-drafts/ > >      > >      > _______________________________________________ >      > L2sm mailing list >      > L2sm@ietf.org >      > https://www.ietf.org/mailman/listinfo/l2sm > >      > >      > Questo messaggio e i suoi allegati sono indirizzati > esclusivamente alle >      persone >      > indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla >      conoscenza di >      > queste informazioni sono rigorosamente vietate. Qualora > abbiate ricevuto >      > questo documento per errore siete cortesemente pregati > di darne immediata >      > comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. >      > >      > This e-mail and any attachments is confidential and may > contain privileged >      > information intended for the addressee(s) only. > Dissemination, copying, >      printing >      > or use by anybody else is unauthorised. If you are not > the intended recipient, >      > please delete this message and any attachments and > advise the sender by return >      > e-mail, Thanks. >      > >      > Rispetta l'ambiente. Non stampare questa mail se non è > necessario. >      > >      > _______________________________________________ >      > L2sm mailing list >      > L2sm@ietf.org >      > https://www.ietf.org/mailman/listinfo/l2sm > >           _______________________________________________ >      L2sm mailing list > L2sm@ietf.org > https://www.ietf.org/mailman/listinfo/l2sm > > > > _______________________________________________ > L2sm mailing list > L2sm@ietf.org > https://www.ietf.org/mailman/listinfo/l2sm > > > --------------7FFAA49EC90B43D2A941B579 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Andrew,
Benoit,

We do that all the time. A recent example is draft-ietf-lpwan-overview.
draft-ietf-lpwan-overview is overview type of documents, so that makes sense.
In this example, we speak of competing or overlapping efforts. At least some people see it that way.
So explaining the relationships between those efforts in a way that will satisfy everybody seems very difficult, if not impossible to me.
In those of situations, my view is pragmatic: let the market decide.

Regards, Benoit

Cheers,
Andy


On Mon, Jan 22, 2018 at 11:46 AM, Benoit Claise <bclaise@cisco.com> wrote:
Hi Roque,

While I understand the willingness to understand the big picture, I don't believe it's appropriate for an IETF document to describe what is happening in different efforts in the industry.

Regards, Benoit

Hi Adrian,

One point that I would like to raise is that it would be important to describe the relationship between this work and what is happening at other standardization bodies such as the MEF Legato YANG service modules and the TAPI work at the ONF.

Regards,
Roque

Ref MEF Legato YANG modules: https://github.com/MEF-GIT/YANG-public/tree/master/src/model/draft


On 17/01/18 10:02, "L2sm on behalf of Adrian Farrel" <l2sm-bounces@ietf.org on behalf of adrian@olddog.co.uk> wrote:

     All,
          We're approaching Working Groups last call on our draft.
          - I have requested a YANG Doctor review of the current revision
     - I plan to do an English language review at the same time (unless
        someone else want to volunteer)
     - NOW is the time for you to do your technical review. Don't leave
        is until WG last call!
     - All things being equal, we will have WG last call in early February
          Thanks,
          Adrian
          > -----Original Message-----
     > From: L2sm [mailto:l2sm-bounces@ietf.org] On Behalf Of Fioccola Giuseppe
     > Sent: 16 January 2018 10:05
     > To: l2sm@ietf.org
     > Cc: draft-ietf-l2sm-l2vpn-service-model@ietf.org; l2sm-chairs@ietf.org
     > Subject: [L2sm] I: I-D Action: draft-ietf-l2sm-l2vpn-service-model-05.txt
     >
     > Hi All,
     > This is the new version of the draft-ietf-l2sm-l2vpn-service-model.
     > It addresses some comments from people that are trying to implement the draft
     > and it includes also an update to the references in particular to RFC8199 and
     > RFC8309.
     > As usual, the fundamental changes are summarized in the Appendix A "Changes
     > Log":
     >
     >    Changes in v-(05) include:
     >
     >    o  Change type from 16-bit integer to string for the leaf id under
     >       "qos-classification-policy" container.
     >
     >    o  Stick to using ordered-by user and remove inefficiency to map
     >       service model sequence number to device model sequence number.
     >
     >    o  Remove mandating the use of deviations and add "if-feature target-
     >       sites" under the leaf-list target-sites in section 5.10.2.
     >
     >    o  RFC2119 language changes on operation of the management system in
     >       Section 5.6,3rd paragraph and section 7.
     >
     >    o  Fix incomplete description statements.
     >
     >    o  Change the use of the absolute paths to the use of relative paths
     >       in the "must" statement or "path" statement for vpn-policy-id leaf
     >       node, management container, location leaf node, devices container,
     >       location case, location-reference leaf, device case, device-
     >       reference leaf to make configuration is only applicable to the
     >       current sites.
     >
     >    o  Change "must" statement to "when" statement for management
     >       container device container.
     >
     >    o  Define new grouping vpn-profile-cfg for all the identifiers
     >       provided by SP to the customer.  The identifiers include cloud-
     >       identifier, std-qos-profile.
     >
     >    o  Add in the XPATH string representation and remove unqualified
     >       name.
     >
     >    o  Remove redundant parameters in the cloud access.
     >
     >    o  Add a few text to clarify what the site is in section 6.3.
     >
     >    o  Add multi-filter and multi-VPN per entry support for VPN policy.
     >
     >    o  Modify description for svc-bandwidth leaf to make it consistent
     >       with the text in section 5.10.1.
     >
     >    o  Add text to clarify the way to achieve Per-VPN QoS policy.
     >
     >    o  Change guaranteed-bw-percent data type from uint8 to decimal64.
     >
     >
     > Reviews and Comments are always welcome.
     >
     > Best Regards,
     >
     > Giuseppe
     >
     > -----Messaggio originale-----
     > Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di internet-drafts@ietf.org
     > Inviato: martedì 16 gennaio 2018 10:46
     > A: i-d-announce@ietf.org
     > Cc: l2sm@ietf.org
     > Oggetto: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-05.txt
     >
     >
     > A New Internet-Draft is available from the on-line Internet-Drafts
     directories.
     > This draft is a work item of the L2VPN Service Model WG of the IETF.
     >
     >         Title           : A YANG Data Model for L2VPN Service Delivery
     >         Authors         : Bin Wen
     >                           Giuseppe Fioccola
     >                           Chongfeng Xie
     >                           Luay Jalil
     >  Filename        : draft-ietf-l2sm-l2vpn-service-model-05.txt
     >  Pages           : 149
     >  Date            : 2018-01-16
     >
     > Abstract:
     >    This document defines a YANG data model that can be used to configure
     >    a Layer 2 Provider Provisioned VPN service.
     >
     >    This model is intended to be instantiated at management system to
     >    deliver the overall service.  This model is not a configuration model
     >    to be used directly on network elements, but provides an abstracted
     >    view of the Layer 2 VPN service configuration components.  It is up
     >    to a management system to take this as an input and generate specific
     >    configurations models to configure the different network elements to
     >    deliver the service.  How configuration of network elements is done
     >    is out of scope of the document.
     >
     >    The data model in this document includes support for point-to-point
     >    Virtual Private Wire Services (VPWS) and multipoint Virtual Private
     >    LAN services (VPLS) that use Pseudowires signaled using the Label
     >    Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as
     >    described in RFC4761 and RFC6624.
     >
     >
     >
     > The IETF datatracker status page for this draft is:
     > https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/
     >
     > There are also htmlized versions available at:
     > https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-05
     > https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-05
     >
     > A diff from the previous version is available at:
     > https://www.ietf.org/rfcdiff?url2=draft-ietf-l2sm-l2vpn-service-model-05
     >
     >
     > Please note that it may take a couple of minutes from the time of submission
     > until the htmlized version and diff are available at tools.ietf.org.
     >
     > Internet-Drafts are also available by anonymous FTP at:
     > ftp://ftp.ietf.org/internet-drafts/
     >
     > _______________________________________________
     > L2sm mailing list
     > L2sm@ietf.org
     > https://www.ietf.org/mailman/listinfo/l2sm
     >
     > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
     persone
     > indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
     conoscenza di
     > queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto
     > questo documento per errore siete cortesemente pregati di darne immediata
     > comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
     >
     > This e-mail and any attachments is confidential and may contain privileged
     > information intended for the addressee(s) only. Dissemination, copying,
     printing
     > or use by anybody else is unauthorised. If you are not the intended recipient,
     > please delete this message and any attachments and advise the sender by return
     > e-mail, Thanks.
     >
     > Rispetta l'ambiente. Non stampare questa mail se non è necessario.
     >
     > _______________________________________________
     > L2sm mailing list
     > L2sm@ietf.org
     > https://www.ietf.org/mailman/listinfo/l2sm
          _______________________________________________
     L2sm mailing list
     L2sm@ietf.org
     https://www.ietf.org/mailman/listinfo/l2sm
     

_______________________________________________
L2sm mailing list
L2sm@ietf.org
https://www.ietf.org/mailman/listinfo/l2sm


--------------7FFAA49EC90B43D2A941B579-- From nobody Tue Jan 23 09:49:47 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D911275FD; Tue, 23 Jan 2018 09:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9pLKP0RIyT3; Tue, 23 Jan 2018 09:49:42 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 3EF5D1275C5; Tue, 23 Jan 2018 09:49:42 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id s11so925317oih.11; Tue, 23 Jan 2018 09:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g9G7YQ6duOnICDfgphhUYin70LOKCGTT1gA/quSsqAo=; b=mufl1eH99YQjZe2fdk/IdiVCmCUUk9iOXbmvsd1aEHR5yimuVeW2StPE8SfmJtKlGj thiVYD4m6ub9otmgbg9QYqxwyGz+IcaaYB2uJTJ1t83cs3QDHsNRMVw5w9MHyR84LRU5 csuzS+GECHEd5A2lh6kqacWMcOtZg7VRoC64TeqzBIVcq4UwDKOEO3LpSBIwE1doTmxj cu4o11okzWWSjlg1oYAiZgVDK204Bmvvj4ZolpZrBJ0rWUrlpnKtB5Io0e1IvX+vN1Np 5vWNPybthMkAOxFuvJGx0cMHfWcWbxDs7x9ahLpHcsulXABPT1JGuaqk3VpWtheiAi48 AIuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g9G7YQ6duOnICDfgphhUYin70LOKCGTT1gA/quSsqAo=; b=SWC6anmQzzszcKR/Nj6D4UOWmd3izurTx1b+UVh9dr5zcFyJ86Yxb8LMZK9Ukt+PkO PaJk2t43rYx596Am/Y1qxjVTtfblQel8QgDOOCZqYeFRYYSn8yv72t0CrxT0lEQRw7g1 s0ntdXc6z0j4tROlT+XXL3PqNHQhJ8u6G+vofoeFxEVZlcmfEitsz7Lo9KQsj37hsoz6 kTniFEYbezAFjdJN6zSD4LkOlHbtr3x7pBNnW6mpb5wCJeiTJ3EhShZ9whvuYO41Z50C COpm+rEe+oEv7/VQPawDX/4EcE472QmxRhBc/YpRLk5axtB0W9iyFlnYvf7MeVtm0962 s59w== X-Gm-Message-State: AKwxytfRONksB0Hyob2pckZxfLwA9WYv+nqkfSHbCGCslQKpQ9BcOCQB rywPDGe3LSJB54Yjsw0L9xk9hBq5N2et2Z/oduY= X-Google-Smtp-Source: AH8x227h5JEf2iUjpvEFoXtzAYLEx0hGT64B9jFsldli1iVaPRxjp5cNSfWdIoUvl4iT6pZkW3dEsMC6KXID5k1h2TU= X-Received: by 10.202.237.88 with SMTP id l85mr6728571oih.296.1516729781388; Tue, 23 Jan 2018 09:49:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.27.211 with HTTP; Tue, 23 Jan 2018 09:49:20 -0800 (PST) In-Reply-To: References: <058701d38f71$d52d2b60$7f878220$@olddog.co.uk> <47CEAC7E-BCD8-4B93-BB2A-2EFACDD55223@cisco.com> <7381e8c5-9481-62b7-f11f-f0dc0bfcae0c@cisco.com> From: "Andrew G. Malis" Date: Tue, 23 Jan 2018 12:49:20 -0500 Message-ID: To: Benoit Claise Cc: "Roque Gagliano (rogaglia)" , "adrian@olddog.co.uk" , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" , "l2sm-chairs@ietf.org" , "l2sm@ietf.org" Content-Type: multipart/alternative; boundary="001a113dee6ad7096b0563752b45" Archived-At: Subject: Re: [L2sm] Next steps with draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 17:49:46 -0000 --001a113dee6ad7096b0563752b45 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Benoit, Perhaps Roque could contribute some text, so we would have something concrete to discuss rather than just in the abstract. This could perhaps go into an informative appendix, if the WG approves including it. This could make for a more informed market to make its decisions. Cheers, Andy On Tue, Jan 23, 2018 at 8:01 AM, Benoit Claise wrote: > Andrew, > > Benoit, > > We do that all the time. A recent example is draft-ietf-lpwan-overview. > > draft-ietf-lpwan-overview is overview type of documents, so that makes > sense. > In this example, we speak of competing or overlapping efforts. At least > some people see it that way. > So explaining the relationships between those efforts in a way that will > satisfy everybody seems very difficult, if not impossible to me. > In those of situations, my view is pragmatic: let the market decide. > > Regards, Benoit > > > Cheers, > Andy > > > On Mon, Jan 22, 2018 at 11:46 AM, Benoit Claise wrote= : > >> Hi Roque, >> >> While I understand the willingness to understand the big picture, I don'= t >> believe it's appropriate for an IETF document to describe what is happen= ing >> in different efforts in the industry. >> >> Regards, Benoit >> >> Hi Adrian, >>> >>> One point that I would like to raise is that it would be important to >>> describe the relationship between this work and what is happening at ot= her >>> standardization bodies such as the MEF Legato YANG service modules and = the >>> TAPI work at the ONF. >>> >>> Regards, >>> Roque >>> >>> Ref MEF Legato YANG modules: https://github.com/MEF-GIT/YAN >>> G-public/tree/master/src/model/draft >>> >>> >>> On 17/01/18 10:02, "L2sm on behalf of Adrian Farrel" < >>> l2sm-bounces@ietf.org on behalf of adrian@olddog.co.uk> wrote: >>> >>> All, >>> We're approaching Working Groups last call on our draft. >>> - I have requested a YANG Doctor review of the current revisi= on >>> - I plan to do an English language review at the same time (unless >>> someone else want to volunteer) >>> - NOW is the time for you to do your technical review. Don't leave >>> is until WG last call! >>> - All things being equal, we will have WG last call in early >>> February >>> Thanks, >>> Adrian >>> > -----Original Message----- >>> > From: L2sm [mailto:l2sm-bounces@ietf.org] On Behalf Of Fioccola >>> Giuseppe >>> > Sent: 16 January 2018 10:05 >>> > To: l2sm@ietf.org >>> > Cc: draft-ietf-l2sm-l2vpn-service-model@ietf.org; >>> l2sm-chairs@ietf.org >>> > Subject: [L2sm] I: I-D Action: draft-ietf-l2sm-l2vpn-service- >>> model-05.txt >>> > >>> > Hi All, >>> > This is the new version of the draft-ietf-l2sm-l2vpn-service- >>> model. >>> > It addresses some comments from people that are trying to >>> implement the draft >>> > and it includes also an update to the references in particular t= o >>> RFC8199 and >>> > RFC8309. >>> > As usual, the fundamental changes are summarized in the Appendix >>> A "Changes >>> > Log": >>> > >>> > Changes in v-(05) include: >>> > >>> > o Change type from 16-bit integer to string for the leaf id >>> under >>> > "qos-classification-policy" container. >>> > >>> > o Stick to using ordered-by user and remove inefficiency to >>> map >>> > service model sequence number to device model sequence >>> number. >>> > >>> > o Remove mandating the use of deviations and add "if-feature >>> target- >>> > sites" under the leaf-list target-sites in section 5.10.2. >>> > >>> > o RFC2119 language changes on operation of the management >>> system in >>> > Section 5.6,3rd paragraph and section 7. >>> > >>> > o Fix incomplete description statements. >>> > >>> > o Change the use of the absolute paths to the use of relativ= e >>> paths >>> > in the "must" statement or "path" statement for >>> vpn-policy-id leaf >>> > node, management container, location leaf node, devices >>> container, >>> > location case, location-reference leaf, device case, devic= e- >>> > reference leaf to make configuration is only applicable to >>> the >>> > current sites. >>> > >>> > o Change "must" statement to "when" statement for management >>> > container device container. >>> > >>> > o Define new grouping vpn-profile-cfg for all the identifier= s >>> > provided by SP to the customer. The identifiers include >>> cloud- >>> > identifier, std-qos-profile. >>> > >>> > o Add in the XPATH string representation and remove >>> unqualified >>> > name. >>> > >>> > o Remove redundant parameters in the cloud access. >>> > >>> > o Add a few text to clarify what the site is in section 6.3. >>> > >>> > o Add multi-filter and multi-VPN per entry support for VPN >>> policy. >>> > >>> > o Modify description for svc-bandwidth leaf to make it >>> consistent >>> > with the text in section 5.10.1. >>> > >>> > o Add text to clarify the way to achieve Per-VPN QoS policy. >>> > >>> > o Change guaranteed-bw-percent data type from uint8 to >>> decimal64. >>> > >>> > >>> > Reviews and Comments are always welcome. >>> > >>> > Best Regards, >>> > >>> > Giuseppe >>> > >>> > -----Messaggio originale----- >>> > Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di >>> internet-drafts@ietf.org >>> > Inviato: marted=C3=AC 16 gennaio 2018 10:46 >>> > A: i-d-announce@ietf.org >>> > Cc: l2sm@ietf.org >>> > Oggetto: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service- >>> model-05.txt >>> > >>> > >>> > A New Internet-Draft is available from the on-line Internet-Draf= ts >>> directories. >>> > This draft is a work item of the L2VPN Service Model WG of the >>> IETF. >>> > >>> > Title : A YANG Data Model for L2VPN Service >>> Delivery >>> > Authors : Bin Wen >>> > Giuseppe Fioccola >>> > Chongfeng Xie >>> > Luay Jalil >>> > Filename : draft-ietf-l2sm-l2vpn-service-model-05.txt >>> > Pages : 149 >>> > Date : 2018-01-16 >>> > >>> > Abstract: >>> > This document defines a YANG data model that can be used to >>> configure >>> > a Layer 2 Provider Provisioned VPN service. >>> > >>> > This model is intended to be instantiated at management syste= m >>> to >>> > deliver the overall service. This model is not a >>> configuration model >>> > to be used directly on network elements, but provides an >>> abstracted >>> > view of the Layer 2 VPN service configuration components. It >>> is up >>> > to a management system to take this as an input and generate >>> specific >>> > configurations models to configure the different network >>> elements to >>> > deliver the service. How configuration of network elements i= s >>> done >>> > is out of scope of the document. >>> > >>> > The data model in this document includes support for >>> point-to-point >>> > Virtual Private Wire Services (VPWS) and multipoint Virtual >>> Private >>> > LAN services (VPLS) that use Pseudowires signaled using the >>> Label >>> > Distribution Protocol (LDP) and the Border Gateway Protocol >>> (BGP) as >>> > described in RFC4761 and RFC6624. >>> > >>> > >>> > >>> > The IETF datatracker status page for this draft is: >>> > https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-servi >>> ce-model/ >>> > >>> > There are also htmlized versions available at: >>> > https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-mo >>> del-05 >>> > https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn- >>> service-model-05 >>> > >>> > A diff from the previous version is available at: >>> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2sm-l2vpn-serv >>> ice-model-05 >>> > >>> > >>> > Please note that it may take a couple of minutes from the time o= f >>> submission >>> > until the htmlized version and diff are available at >>> tools.ietf.org. >>> > >>> > Internet-Drafts are also available by anonymous FTP at: >>> > ftp://ftp.ietf.org/internet-drafts/ >>> > >>> > _______________________________________________ >>> > L2sm mailing list >>> > L2sm@ietf.org >>> > https://www.ietf.org/mailman/listinfo/l2sm >>> > >>> > Questo messaggio e i suoi allegati sono indirizzati >>> esclusivamente alle >>> persone >>> > indicate. La diffusione, copia o qualsiasi altra azione derivant= e >>> dalla >>> conoscenza di >>> > queste informazioni sono rigorosamente vietate. Qualora abbiate >>> ricevuto >>> > questo documento per errore siete cortesemente pregati di darne >>> immediata >>> > comunicazione al mittente e di provvedere alla sua distruzione, >>> Grazie. >>> > >>> > This e-mail and any attachments is confidential and may contain >>> privileged >>> > information intended for the addressee(s) only. Dissemination, >>> copying, >>> printing >>> > or use by anybody else is unauthorised. If you are not the >>> intended recipient, >>> > please delete this message and any attachments and advise the >>> sender by return >>> > e-mail, Thanks. >>> > >>> > Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 nece= ssario. >>> > >>> > _______________________________________________ >>> > L2sm mailing list >>> > L2sm@ietf.org >>> > https://www.ietf.org/mailman/listinfo/l2sm >>> _______________________________________________ >>> L2sm mailing list >>> L2sm@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2sm >>> >>> >> >> _______________________________________________ >> L2sm mailing list >> L2sm@ietf.org >> https://www.ietf.org/mailman/listinfo/l2sm >> > > > --001a113dee6ad7096b0563752b45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Benoit,

Perhaps Roque could contribute = some text, so we would have something concrete to discuss rather than just = in the abstract. This could perhaps go into an informative appendix, if the= WG approves including it. This could make for a more informed market to ma= ke its decisions.

Cheers,
Andy

On Tue, Jan 23,= 2018 at 8:01 AM, Benoit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
Andrew,
=20
Benoit,

We do that all the time. A recent example is draft-ietf-lpwan-overview.
 draft-ietf-lpwan-overview is overview type of documents, so that makes sense.
In this example, we speak of competing or overlapping efforts. At least some people see it that way.
So explaining the relationships between those efforts in a way that will satisfy everybody seems very difficult, if not impossible to me.
In those of situations, my view is pragmatic: let the market decide.
Regards, Benoit


Cheers,
Andy


On Mon, Jan 22, 2018 at 11:46 AM, Benoit Claise <bclaise@cisco.com> wrote:
Hi Roque,

While I understand the willingness to understand the big picture, I don't believe it's appropriate for an IETF document to describe what is happening in different efforts in the industry.

Regards, Benoit

Hi Adrian,

One point that I would like to raise is that it would be important to describe the relationship between this work and what is happening at other standardization bodies such as the MEF Legato YANG service modules and the TAPI work at the ONF.

Regards,
Roque

Ref MEF Legato YANG modules: https://github.com/MEF-GIT/YANG-public/tree/master/src/mo= del/draft


On 17/01/18 10:02, "L2sm on behalf of Adrian Farrel&= quot; <l2sm-bounces@ietf.org on behalf of adrian@olddog.co.uk> wrote:

=C2=A0 =C2=A0 =C2=A0All,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We're approaching = Working Groups last call on our draft.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - I have requested a Y= ANG Doctor review of the current revision
=C2=A0 =C2=A0 =C2=A0- I plan to do an English language re= view at the same time (unless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 someone else want to voluntee= r)
=C2=A0 =C2=A0 =C2=A0- NOW is the time for you to do your = technical review. Don't leave
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is until WG last call!
=C2=A0 =C2=A0 =C2=A0- All things being equal, we will hav= e WG last call in early February
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adrian
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > -----Original Mes= sage-----
=C2=A0 =C2=A0 =C2=A0> From: L2sm [mailto:l2sm-bounces@ietf.org] On Behalf Of Fioccola Giuseppe
=C2=A0 =C2=A0 =C2=A0> Sent: 16 January 2018 10:05
=C2=A0 =C2=A0 =C2=A0> To: l2sm@ietf.org
=C2=A0 =C2=A0 =C2=A0> Cc: draft-ietf-l2sm-l2vpn= -service-model@ietf.org; l2sm-chairs@ietf.org
=C2=A0 =C2=A0 =C2=A0> Subject: [L2sm] I: I-D Action: draft-ietf-l2sm-l2vpn-service-model-05.txt
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Hi All,
=C2=A0 =C2=A0 =C2=A0> This is the new version of the draft-ietf-l2sm-l2vpn-service-model.
=C2=A0 =C2=A0 =C2=A0> It addresses some comments from = people that are trying to implement the draft
=C2=A0 =C2=A0 =C2=A0> and it includes also an update t= o the references in particular to RFC8199 and
=C2=A0 =C2=A0 =C2=A0> RFC8309.
=C2=A0 =C2=A0 =C2=A0> As usual, the fundamental change= s are summarized in the Appendix A "Changes
=C2=A0 =C2=A0 =C2=A0> Log":
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Changes in v-(05) i= nclude:
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Change type= from 16-bit integer to string for the leaf id under
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0"= qos-classification-policy" container.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Stick to us= ing ordered-by user and remove inefficiency to map
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0servic= e model sequence number to device model sequence number.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Remove mand= ating the use of deviations and add "if-feature target-
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0sites&= quot; under the leaf-list target-sites in section 5.10.2.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 RFC2119 lan= guage changes on operation of the management system in
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sectio= n 5.6,3rd paragraph and section 7.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Fix incompl= ete description statements.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Change the = use of the absolute paths to the use of relative paths
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in the= "must" statement or "path" statement for vpn-policy-id leaf
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0node, = management container, location leaf node, devices container,
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0locati= on case, location-reference leaf, device case, device-
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0refere= nce leaf to make configuration is only applicable to the
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0curren= t sites.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Change &quo= t;must" statement to "when" statement for management
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0contai= ner device container.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Define new = grouping vpn-profile-cfg for all the identifiers
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0provid= ed by SP to the customer.=C2=A0 The identifiers include cloud-
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0identi= fier, std-qos-profile.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Add in the = XPATH string representation and remove unqualified
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0name.<= br> =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Remove redu= ndant parameters in the cloud access.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Add a few t= ext to clarify what the site is in section 6.3.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Add multi-f= ilter and multi-VPN per entry support for VPN policy.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Modify desc= ription for svc-bandwidth leaf to make it consistent
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with t= he text in section 5.10.1.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Add text to= clarify the way to achieve Per-VPN QoS policy.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 o=C2=A0 Change guar= anteed-bw-percent data type from uint8 to decimal64.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Reviews and Comments are always = welcome.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Best Regards,
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Giuseppe
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> -----Messaggio originale----- =C2=A0 =C2=A0 =C2=A0> Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di internet-drafts@ietf.org
=C2=A0 =C2=A0 =C2=A0> Inviato: marted=C3=AC 16 gennaio= 2018 10:46
=C2=A0 =C2=A0 =C2=A0> A: i-d-announce@ietf.org
=C2=A0 =C2=A0 =C2=A0> Cc: l2sm@ietf.org
=C2=A0 =C2=A0 =C2=A0> Oggetto: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-05.txt
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> A New Internet-Draft is availabl= e from the on-line Internet-Drafts
=C2=A0 =C2=A0 =C2=A0directories.
=C2=A0 =C2=A0 =C2=A0> This draft is a work item of the= L2VPN Service Model WG of the IETF.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A YANG Data Model for L2VPN Service Delivery
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bin Wen
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Giuseppe = Fioccola
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Chongfeng= Xie
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Luay Jali= l
=C2=A0 =C2=A0 =C2=A0>=C2=A0 Filename=C2=A0 =C2=A0 =C2= =A0 =C2=A0 : draft-ietf-l2sm-l2vpn-service-model-05.txt
=C2=A0 =C2=A0 =C2=A0>=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: 149
=C2=A0 =C2=A0 =C2=A0>=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : 2018-01-16
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Abstract:
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 This document defin= es a YANG data model that can be used to configure
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 a Layer 2 Provider = Provisioned VPN service.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 This model is inten= ded to be instantiated at management system to
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 deliver the overall= service.=C2=A0 This model is not a configuration model
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 to be used directly= on network elements, but provides an abstracted
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 view of the Layer 2= VPN service configuration components.=C2=A0 It is up
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 to a management sys= tem to take this as an input and generate specific
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 configurations mode= ls to configure the different network elements to
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 deliver the service= .=C2=A0 How configuration of network elements is done
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 is out of scope of = the document.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 The data model in t= his document includes support for point-to-point
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Virtual Private Wir= e Services (VPWS) and multipoint Virtual Private
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 LAN services (VPLS)= that use Pseudowires signaled using the Label
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Distribution Protoc= ol (LDP) and the Border Gateway Protocol (BGP) as
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 described in RFC476= 1 and RFC6624.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> The IETF datatracker status page= for this draft is:
=C2=A0 =C2=A0 =C2=A0> https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-ser= vice-model/
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> There are also htmlized versions= available at:
=C2=A0 =C2=A0 =C2=A0> https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-mo<= wbr>del-05
=C2=A0 =C2=A0 =C2=A0> https://datatracker.ietf.org/doc/html/draft-ietf-l2= sm-l2vpn-service-model-05
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> A diff from the previous version= is available at:
=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2sm-l= 2vpn-service-model-05
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Please note that it may take a c= ouple of minutes from the time of submission
=C2=A0 =C2=A0 =C2=A0> until the htmlized version and d= iff are available at tools.ietf.org.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Internet-Drafts are also availab= le by anonymous FTP at:
=C2=A0 =C2=A0 =C2=A0> ftp://ftp.ietf.org/int= ernet-drafts/
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0> L2sm mailing list
=C2=A0 =C2=A0 =C2=A0> L2sm@ietf.org
=C2=A0 =C2=A0 =C2=A0> https://www.iet= f.org/mailman/listinfo/l2sm
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Questo messaggio e i suoi allega= ti sono indirizzati esclusivamente alle
=C2=A0 =C2=A0 =C2=A0persone
=C2=A0 =C2=A0 =C2=A0> indicate. La diffusione, copia o= qualsiasi altra azione derivante dalla
=C2=A0 =C2=A0 =C2=A0conoscenza di
=C2=A0 =C2=A0 =C2=A0> queste informazioni sono rigoros= amente vietate. Qualora abbiate ricevuto
=C2=A0 =C2=A0 =C2=A0> questo documento per errore siet= e cortesemente pregati di darne immediata
=C2=A0 =C2=A0 =C2=A0> comunicazione al mittente e di p= rovvedere alla sua distruzione, Grazie.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> This e-mail and any attachments = is confidential and may contain privileged
=C2=A0 =C2=A0 =C2=A0> information intended for the add= ressee(s) only. Dissemination, copying,
=C2=A0 =C2=A0 =C2=A0printing
=C2=A0 =C2=A0 =C2=A0> or use by anybody else is unauth= orised. If you are not the intended recipient,
=C2=A0 =C2=A0 =C2=A0> please delete this message and a= ny attachments and advise the sender by return
=C2=A0 =C2=A0 =C2=A0> e-mail, Thanks.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Rispetta l'ambiente. Non sta= mpare questa mail se non =C3=A8 necessario.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0> L2sm mailing list
=C2=A0 =C2=A0 =C2=A0> L2sm@ietf.org
=C2=A0 =C2=A0 =C2=A0> https://www.iet= f.org/mailman/listinfo/l2sm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ______________________= _________________________
=C2=A0 =C2=A0 =C2=A0L2sm mailing list
=C2=A0 =C2=A0 =C2=A0L2sm@ietf.org
=C2=A0 =C2=A0 =C2=A0https://www.ietf.org= /mailman/listinfo/l2sm
=C2=A0 =C2=A0 =C2=A0

_______________________________________________
L2sm mailing list
L2sm@iet= f.org
https://www.ietf.org/mailman/listinf= o/l2sm



--001a113dee6ad7096b0563752b45-- From nobody Wed Jan 31 06:32:59 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E41A12EB8A; Wed, 31 Jan 2018 06:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYwg_xf1EBT5; Wed, 31 Jan 2018 06:32:53 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9355F1317F2; Wed, 31 Jan 2018 06:31:08 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0VEV6EN003904; Wed, 31 Jan 2018 14:31:06 GMT Received: from 950129200 ([193.57.120.142]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0VEV1xh003825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jan 2018 14:31:03 GMT Reply-To: From: "Adrian Farrel" To: Cc: , "'Jan Lindblad'" References: <058801d38f72$7526d800$5f748800$@olddog.co.uk> <16F8CDDD-6FB9-4C29-BE19-31C398540303@tail-f.com> <05c101d38f88$482eb0a0$d88c11e0$@olddog.co.uk> In-Reply-To: Date: Wed, 31 Jan 2018 14:31:02 -0000 Message-ID: <0b4b01d39aa0$1f91f3a0$5eb5dae0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B4C_01D39AA0.1FBA8A40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGbYYMLnOH+20pqSyT8FxtWyiFAXQLBgAiWAcQeilMCRvT87aPIFyEQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23632.007 X-TM-AS-Result: No--18.034-10.0-31-10 X-imss-scan-details: No--18.034-10.0-31-10 X-TMASE-MatchedRID: AXqs4r+tk3JHdhuYYkLbTLdQIb8hCnY+rHCvytg5b4495QkkroABJbT1 PfFb2aa8SREnFCYlEy37J7KZNCMUZiP0K6pQJfW4b/5HBZ6dvRgS12tj9Zvd8xKIr6MHZFJ1r3A g3zt3L14i4bZCUUt3BoEN02vEC7aDo4XUuMvTVpQjK+nUBBcfy5ACgmEvxn6vYIPlIzxi9UUrjL 21lsVzzlUJN3KkiTtdrouWMPKBA/FnEZWl/y7mGc5Scd0yVs+bCQ3xS+zL6e34JyR+b5tvoPRm0 kmqtH+D3pye3Whh2REEyKTjjDAwEK2QcrcGaiYgliwpJdZauweZf5btvM85AXX+rbovv1tMzw+o FzYqJkf+f0nlDYjAjtlYmtBNW3IbrCSDvRpy10RsG7r4Qh7N3BU5qsA/dJ7CDpCUEeEFm7B8rwA wWerBmDEkM/dhR7QFk2JnmeZE9gi1Ha+bMGdk0xIRh9wkXSlFdwX/SSKrKHizXLgm/AgMbgfoRw TLQ8VIci6AUyYpyt+U9QSsHUHEBsfeJfU5DGcLCFaAixm5eU8UkWvaqUqLH7iBTLMkgNsWJUgu5 qZIX1dILvrkd8n3SjNcGg4YDGurs9gvQBjr0DSRGzV8Bxg0cUCrr/LkAQ46LcVjbs+keawgkXq/ YVYC+O8BtdISrVH6q7Fs15iXQ7Wjb+Fpw9wtLtjDJsU1r62bojQrbrPpzzpcKZwALwMGs8it/eC fvDyiFcQoBygS/73+yOWquOWfJMJHVFWeMALEjtK7dC6UBnlcSMp/1+EppyfO9H6Y/dy+rBS6zb NxgL6yypnor4OCPqyDYF/RX6N8jBOuHzVSbRGeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDOG2o4D tJIL5vLE5hS3p8W33fj+sMArfOEbaqKQSlAZRow8Kyk3tsB57ywFN4XkPWNg+0X1d6KF8O5kKaV eETKm9JyYX76gYc= Archived-At: Subject: [L2sm] FW: YANG + XML review of draft-ietf-l2sm-l2vpn-service-model-05 X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 14:32:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B4C_01D39AA0.1FBA8A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi authors, Jan Lindblad has done a great review for us. On the positive side he thinks you have done a really good job with the module, but he has nevertheless found a pile of small issues. It looks to me (what do I know ;-) that the majority of these should be really easy to fix, so I'd like to lean on you a bit to get a revision "soon." Can you let us know what the plan is? At the same time, I will do an English language review. Thanks, Adrian From: Jan Lindblad [mailto:janl@tail-f.com] Sent: 31 January 2018 13:48 To: Adrian Farrel Cc: bclaise@cisco.com; Qin Wu Subject: YANG + XML review of draft-ietf-l2sm-l2vpn-service-model-05 Adrian, shepherds, I've now made a YANG review of the l2vpn YANG model and examples. Since I'm not listed as the formal reviewer, I'll just write it in a mail like this. Let me know how you'd like me to post this if this mail to you is not what you had in mind. That's fabulous! We are looking to do WG last call in early February. Of course, incorporating your comments before then would be best, but that would mean completing your review by the end of January. The back-up plan would be to do your review before the end of last call so targeting 20th Feb. So I read the first 35 pages of the RFC before I realized I'm not going to understand this well enough to have any use of the plaintext when looking at the YANG anyway. So then I jumped right at the YANG and examples instead. I must say it's a clean and simple approach and one of the more well written YANGs I have seen; I could not find any serious issues with it. Since it's written in a very down to earth fashion without much in terms of fancy constructs, it stays clear of some of the pitfalls we've seen in the past. When it comes to the examples, they all omit things (which may or may not be acceptable, you decide) and almost all the examples are broken. In other words, business as usual. On the detailed level I have a long list of comments. Mostly the usual stuff. So here goes: General: -- indentation is broken General: feature dot1q{ -- missing space between name and open brace in lots of places General: identity opaque { base bw-type; description "Opaque"; -- descriptions like this have negative value, no information but take up space. I would have hoped to understand how/when to use "opaque", etc. 46: feature L2CP-control { 443: identity all2one-Bundling { -- should be all lowercase 80: feature signaling-options { description "Enable the support of signalling option."; 3001: leaf signalling-type { -- make spelling consistent; either "signaling" or "signalling". Our own XML examples below stumble over this as well 365: identity site-vpn-flavor-single { 371: identity site-vpn-flavor-multi { 381: identity site-vpn-flavor-nni { 601: identity co-managed { 606: identity customer-managed { 611: identity provider-managed { 616: identity address-family { -- remove the word "Base" in the description, these are identities, but not base identities 454: identity color-id--cvlan { 468: identity cos-id--dscp { -- use single dash 906: identity bidirection { -- should be "bidirectional" ? 1024: choice list-flavor { 1064: leaf site-vpn-flavor { 1252: leaf delivery-mode { 1452: leaf bundling-type { 1459: leaf default-ce-vlan-id { 1469: grouping cfm-802-grouping { (one leaf has a default) 1538: grouping y-1731 { 1650: grouping lacp-grouping { 1672: leaf system-priority { 1830: leaf enable { 1838: leaf uni-loop-prevention { 1888: leaf tag-type { 1895: leaf cvlan-id { 1909: leaf tag-type { 1925: leaf tag-type { 1932: leaf svlan-id { 1937: leaf cvlan-id { 1951: leaf tag-type { 1958: leaf svlan-id { 1972: leaf vni-id { 1977: leaf peer-mode { 2005: leaf encapsulation-type { 2012: leaf eth-inf-type { 2049: grouping svc-preservation-grouping { 2073: grouping site-mac-addr-limit { 2105: leaf access-priority { 2139: grouping l2cp-grouping { 2199: grouping site-bum { 2275: grouping site-mac-loop-prevention { 2301: grouping ethernet-svc-oam-grouping { 2327: grouping fate-sharing-group { 2452: choice request-type-choice { 2542: leaf attachment-device-id { 2577: leaf vpn-id { 2648: leaf vpn-id { 2653: leaf cir { 2661: leaf cbs { 2855: leaf direction { 2863: leaf policing { 2879: choice flavor { 2907: choice flavor { 3001: leaf signalling-type { 3135: leaf svc-type { 3147: leaf svc-topo { 3203: leaf remote-carrier-name { -- no default, no mandatory, no description what happens if not set. Groupings included above when every leaf inside is lacking default/mandatory/description 1171: list filter { -- only one filter of each type (and only one standard type). Will there ever be a filter that you'd want to have several of? 1211: mandatory true; -- redundant, this is already a key, hence mandatory 1349: leaf group-id { 1718: leaf profile-name { 1779: leaf flow-control { 1818: leaf flow-control { 2334: leaf group-color { 2341: leaf group-id { 2362: leaf group-id { 2399: leaf group-id { 2455: leaf physical-if { 2472: leaf physical-if { 2477: leaf circuit-id { 2499: leaf requested-type { 2542: leaf attachment-device-id { 3203: leaf remote-carrier-name { -- These use type string, is that really the right type? How about leafref, enumeration, ...? What are the valid values here? What happens if an "incorrect" value is given? 1563: leaf message-period { 1569: leaf measurement-interval { 1662: leaf lacp-speed { 1667: leaf mini-link { 1695: leaf bfd-interval { 1700: leaf bfd-hold-timer { 1748: leaf port-speed { 1803: leaf port-speed { 2245: leaf bum-overall-rate { 2259: leaf rate { 2277: leaf frequency { 2935: leaf fr-loss-rate { -- add units. In some cases unit is specified in the description, but better in units stmt. 1107: leaf management-transport { 1650: grouping lacp-grouping { 1652: leaf lacp-state { 1657: leaf lacp-mode { 1662: leaf lacp-speed { 1681: leaf micro-bfd-on-off { 1695: leaf bfd-interval { 1700: leaf bfd-hold-timer { 1710: leaf bfd-hold-timer { 1857: leaf lag-ifindex { 1875: leaf tagged-inf-type { 2075: leaf mac-num-limit { 2776: container qos-classification-policy { 2824: container qos-profile { 2935: leaf fr-loss-rate { 3060: leaf site-network-access-type { -- remove redundant part of the name. Inside container bfd, leaf:s should not be called bfd-foo, but just foo 1652: leaf lacp-state { -- wouldn't "enable" be a better name than "state" for an on/off switch? 1657: leaf lacp-mode { -- what does values true and false mean here? How is this different from leaf lacp-state? 1740: container member-link-list { -- should probably be "member-links" 1798: leaf ifindex { -- how do I know what ifindex value to use? Is this the same ifIndex as in snmp? 1853: container lag-interface { -- should probably be lag-interfaces 2112: leaf single-active { 2121: leaf all-active { -- I think you mean type empty? 2308: leaf md-level { 2792: leaf match-phy-port { -- how do I know what is a good value for this leaf? 2460: leaf vlan-id { -- add a range? 2499: leaf requested-type { -- same name as parent container, confusing Finally, there are seven leafrefs with absolute paths. In the past reviews there have been issues when an absolute path was used but only a relative path had the right semantics. In this case, I don't understand well enough what the author's intent is, so let me verify for each one that the YANG matches the author's intent: 1015: leaf cloud-identifier { -- points to ANY cloud, regardless of profile 1033: leaf-list permit-site { 1042: leaf-list deny-site { -- points to ANY site, regardless of which customer 1206: leaf vpn-id { 1273: leaf svc-id { 2577: leaf vpn-id { -- points to ANY vpn, regardless of which customer 2832: leaf profile { -- points to ANY qos-profile Then we have the XML examples. I refer to them by page number in the spec, with "a" and "b" suffix when there is more than one on a single page. p24a, p24b, p25: The /l2vpn-svc/vpn-services/vpn-service["123456487"]/frame-delivery/multicast-gp-por t-mapping is mandatory and not set by the example. After working a bit with the model, I'd suggest removing mandatory here and add a default instead. It's really a bit annoying to have to care about multicast properties as soon as I define a vpn-service. p26: Example broken in a couple of places: 1. hub-spoke ==> hub-spoke 2. any-to-any ==> any-to-any 3. spoke-role ==> spoke-role p39: Example broken in a couple of places: 1. LA1 ==> LA1 2. LA2 ==> LA2 And a few things are omitted: /l2vpn-svc/sites/site["SITE1"]/service/svc-mtu is mandatory and not included in the example. I'd suggest adding a default instead, the MTU is perhaps not the first thing you think about when defining a new service. Now it has to be given immediately. /l2vpn-svc/sites/site["SITE1"]/management/type is mandatory and not included in the example. As soon as a type is set, a number of other things become mandatory too. Which ones depends on what type you select. /l2vpn-svc/sites/site["SITE1"]/site-network-accesses/site-network-access["LA1"]/ vpn-attachment/vpn-id refers to a VPN that is not defined, but I guess that's acceptable. p41: Example broken: LA1 ==> LA1 Same things omitted as on p39. p42: Example broken in a couple of places: 1. LAN1 ==> lan 17 2. LAN2 ==> lan 18 3. LA1 ==> LA1 Omits service/svc-mtu and management/type like on p39. p60: Example broken in a number of places: 1. NY US ==> NY1 NY US 2. CSP_A_VN1 ==> CSP_A_VN1 3. tagged ==> tagged 4. dot1q-vlan ==> dot1q 5. 17 ==> 17 6. Need to move out of 7. Missing end tag 8. Not making up our mind on how to spell signaling/signalling bites us: bgp ==> bgp Same omissions as on p39. p68a: Example broken: Some unwanted whitespace crept in: vpws ==> vpws /l2vpn-svc/vpn-services/vpn-service["12456487" and "12456488"]/frame-delivery/multicast-gp-port-mapping is mandatory and not configured p68b: Example broken in a number of places: 1. NY US ==> NY1 NY US 2. Double start tags ==> 3. I'm guessing the author means "vlan" when saying "dot1q" ? dot1q ==> vlan 4. Wrong end tag ==> 5. Needs to be lowercase TUNNEL ==> tunnel 6. TRUE ==> true 7. Need to move out of 8. bgp ==> bgp Same omissions as on p39. Obviously, these XML fixes assume an unchanged YANG model. As they YANG is fixed/changed, the examples should follow suit. That's all I found. Thanks! /jan From: Jan Lindblad [mailto:janl@tail-f.com] Sent: 17 January 2018 11:29 To: Adrian Farrel Cc: bclaise@cisco.com; Qin Wu Subject: Re: Cheeky request Adrian, You did such a good job with the L3SMbis draft that it should come as no surprise that we are all queueing up to have you as a reviewer. https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ is now very close to WG last call and we just made a request for "early" YANG Doctor review. But if you were able to look at it as well, that would be rather good. Of course, you are allowed to be tired/bored/busy :-) Flattery is often effective ;-) Thank you for asking. I would certainly be interested to have a good look at all IETF service models, and perhaps better to get into the habit of doing that before the publication rather than after :-/ I guess it's primarily going to be a question of when you need the answer. By when would you need it? Best Regards, /jan -- Jan Lindblad, janl@tail-f.com, +46 702855728 Solutions Architect, Business Development, Tail-f Tail-f is now a part of Cisco ------=_NextPart_000_0B4C_01D39AA0.1FBA8A40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = authors,

 

Jan Lindblad has done a great = review for us.

 

On the positive side he thinks = you have done a really good job with the module, but he has nevertheless = found a pile of small issues.

 

It looks to me (what do I know = ;-) that the majority of these should be really easy to fix, so I'd like = to lean on you a bit to get a revision "soon." Can you let us = know what the plan is?

 

At the same time, I will do an = English language review.

 

Thanks,

Adrian

 

From: Jan Lindblad = [mailto:janl@tail-f.com]
Sent: 31 January 2018 = 13:48
To: Adrian Farrel
Cc: bclaise@cisco.com; Qin = Wu
Subject: YANG + XML review of = draft-ietf-l2sm-l2vpn-service-model-05

<= p class=3DMsoNormal> 

Adrian, = shepherds,

 

I've now made a YANG review of the l2vpn YANG model and = examples. Since I'm not listed as the formal reviewer, I'll just write = it in a mail like this. Let me know how you'd like me to post this if = this mail to you is not what you had in = mind.

 

That's = fabulous!

 

We are looking to do WG = last call in early February. Of course, incorporating your comments = before then would be best, but that would mean completing your review by = the end of January.

 

The back-up plan would be = to do your review before the end of last call so targeting 20th = Feb.

 

So I read the first 35 pages of the RFC before I realized I'm = not going to understand this well enough to have any use of the = plaintext when looking at the YANG anyway. So then I jumped right at the = YANG and examples instead. I must say it's a clean and simple approach = and one of the more well written YANGs I have seen; I could not find any = serious issues with it. Since it's written in a very down to earth = fashion without much in terms of fancy constructs, it stays clear of = some of the pitfalls we've seen in the past. When it comes to the = examples, they all omit things (which may or may not be acceptable, you = decide) and almost all the examples are broken. In other words, business = as usual.

 

On the detailed level I have a long list of comments. Mostly the = usual stuff. So here goes:

 

General:

-- indentation is broken

 

General:

  feature dot1q{

-- missing space between name and open brace in lots of = places

 

General:

  identity opaque {

    base bw-type;

    description

      = "Opaque";

-- descriptions like this have negative value, no information = but take up space. I would have hoped to understand how/when to use = "opaque", etc.

 

46:  feature L2CP-control = { 

443:  identity = all2one-Bundling {

-- should be all lowercase

 

80:  feature signaling-options {
    = description
      "Enable the support of = signalling option.";

3001:      leaf signalling-type = {

-- make spelling = consistent; either "signaling" or "signalling". Our = own XML examples below stumble over this as = well

 

365:  identity site-vpn-flavor-single = {

371:  identity site-vpn-flavor-multi = {

381:  identity = site-vpn-flavor-nni {

601:  identity co-managed = {

606:  identity = customer-managed {

611:  identity provider-managed = {

616:  identity = address-family {

-- remove the word "Base" in the description, these = are identities, but not base = identities

 

454:  identity color-id--cvlan = { 

468:  identity = cos-id--dscp {

-- use single dash

 

906:  identity bidirection = {

-- should be = "bidirectional" ?

 

1024:        choice list-flavor = {

1064:   =  leaf site-vpn-flavor {

1252:        leaf delivery-mode = {

1452:   =  leaf bundling-type {
1459:    leaf default-ce-vlan-id = {

1469:   = grouping cfm-802-grouping { (one leaf has a = default)

1538:  grouping y-1731 = {

1650:   = grouping lacp-grouping {

1672:       leaf system-priority = {

1830:     =    leaf enable {

1838:      leaf uni-loop-prevention = {

1888:     =    leaf tag-type {

1895:        leaf cvlan-id = {

1909:     =     leaf tag-type {

1925:        leaf tag-type = {

1932:     =    leaf svlan-id {

1937:        leaf cvlan-id = {

1951:     =    leaf tag-type {

1958:        leaf svlan-id = {

1972:     =    leaf vni-id {

1977:        leaf peer-mode = {

2005:     =  leaf encapsulation-type {

2012:      leaf eth-inf-type = {

2049:  grouping = svc-preservation-grouping {

2073: grouping site-mac-addr-limit = {

2105:     =  leaf access-priority {

2139:  grouping l2cp-grouping = {

2199:  grouping = site-bum {

2275:  grouping = site-mac-loop-prevention {

2301:  grouping ethernet-svc-oam-grouping = {

2327:  grouping = fate-sharing-group {

2452:      choice request-type-choice = {

2542:     =  leaf attachment-device-id {

2577:          leaf vpn-id = {

2648:     =    leaf vpn-id {

2653:        leaf cir = {

2661:     =    leaf cbs {

2855:               =  leaf direction {

2863:               =  leaf policing {

2879:                 =  choice flavor {

2907:                 =  choice flavor {

3001:      leaf signalling-type = {

3135:     =    leaf svc-type {

3147:        leaf svc-topo = {

3203:     =        leaf remote-carrier-name = {

-- no default, no = mandatory, no description what happens if not set. Groupings included = above when every leaf inside is lacking = default/mandatory/description

 

1171:             list filter = {

-- only one filter = of each type (and only one standard type). Will there ever be a filter = that you'd want to have several of?

 

1211:               mandatory = true;

-- redundant, this is already a key, hence = mandatory

 

1349:          leaf group-id = {

1718:     =        leaf profile-name = {

1779:     =  leaf flow-control {

1818:      leaf flow-control = {

2334:     =  leaf group-color {

2341:        leaf group-id = {

2362:     =    leaf group-id {

2399:                 =  leaf group-id {

2455:            leaf physical-if = {

2472:     =      leaf physical-if = {

2477:     =      leaf circuit-id {

2499:        leaf requested-type = {

2542:     =  leaf attachment-device-id {

3203:            leaf = remote-carrier-name {

-- These use type string, is that really the right type? How = about leafref, enumeration, ...? What are the valid values here? What = happens if an "incorrect" value is = given?

 

1563:       leaf message-period = {

1569:     =  leaf measurement-interval {

1662:      leaf lacp-speed = {

1667:    =   leaf mini-link {
1695:        leaf = bfd-interval {

1700:     =    leaf bfd-hold-timer {

1748:          leaf port-speed = {
1803:      leaf port-speed = {

2245:     =  leaf bum-overall-rate {

2259:        leaf rate = {

2277:     =  leaf frequency {

2935:                 =  leaf fr-loss-rate {

-- add units. In some cases unit is specified in the = description, but better in units = stmt.

 

1107:          leaf = management-transport {

1650:   grouping lacp-grouping = {

1652:     =  leaf lacp-state {

1657:      leaf lacp-mode = {

1662:     =  leaf lacp-speed {

1681:        leaf micro-bfd-on-off = {

1695:     =    leaf bfd-interval {

1700:        leaf bfd-hold-timer = {

1710:     =    leaf bfd-hold-timer {

1857:        leaf lag-ifindex = {

1875:     =  leaf tagged-inf-type {

2075:      leaf mac-num-limit = {

2776:     =  container qos-classification-policy = {

2824:     =  container qos-profile {

2935:                 =  leaf fr-loss-rate {

3060:    leaf site-network-access-type = {

-- remove redundant = part of the name. Inside container bfd, leaf:s should not be called = bfd-foo, but just foo

 

1652:      leaf lacp-state = {

-- wouldn't = "enable" be a better name than "state" for an on/off = switch?

 

1657:      leaf lacp-mode = {

-- what does values = true and false mean here? How is this different from leaf = lacp-state?

 

1740:      container member-link-list = {

-- should probably = be "member-links"

 

1798:      leaf ifindex = {

-- how do I know = what ifindex value to use? Is this the same ifIndex as in = snmp?

 

1853:    container lag-interface = {

-- should probably = be lag-interfaces

 

2112:          leaf single-active = {

2121:     =      leaf all-active {

-- I think you mean type = empty?

 

2308:      leaf md-level = {

2792:     =           leaf match-phy-port = {

-- how do I know = what is a good value for this leaf?

 

2460:            leaf vlan-id = {

-- add a = range?

 

2499:        leaf requested-type = {

-- same name as = parent container, confusing

 

Finally, there are seven leafrefs with absolute paths. In the = past reviews there have been issues when an absolute path was used but = only a relative path had the right semantics. In this case, I don't = understand well enough what the author's intent is, so let me verify for = each one that the YANG matches the author's = intent:

 

1015:         leaf cloud-identifier = {

-- points to ANY = cloud, regardless of profile

 

1033:            leaf-list = permit-site {

1042:     =        leaf-list deny-site = {

-- points to ANY = site, regardless of which customer

 

1206:            leaf vpn-id = {

1273:     =  leaf svc-id {

2577:          leaf vpn-id = {

-- points to ANY = vpn, regardless of which customer

 

2832:            leaf profile = {

-- points to ANY = qos-profile

 

 

 

Then we have the XML examples. I refer to them by page number in = the spec, with "a" and "b" suffix when there is more = than one on a single page.

 

p24a, p24b, p25:

The = /l2vpn-svc/vpn-services/vpn-service["123456487"]/frame-delivery= /multicast-gp-port-mapping is mandatory and not set by the example. = After working a bit with the model, I'd suggest removing mandatory here = and add a default instead. It's really a bit annoying to have to care = about multicast properties as soon as I define a = vpn-service.

 

p26:

Example broken in a = couple of places:

 

1.

          = <vpn-service-topology>hub-spoke</vpn-service-topology>

=3D=3D>

          = <svc-topo>hub-spoke</svc-topo>

 

2.

          = <vpn-service-topology>any-to-any</vpn-service-topology><= /o:p>

=3D=3D>

          = <svc-topo>any-to-any</svc-topo>

 

3.

                  = <site-role>spoke-role</site-role>

=

=3D=3D>

                  = <local-sites-role>spoke-role</local-sites-role>

 

p39:

Example broken in a couple of = places:

 

1.

      =   =  <site-network-access-id>LA1</site-network-access-id>

=3D=3D>
  =       =  <network-access-id>LA1</network-access-id>

2.

      =   =  <site-network-access-id>LA2</site-network-access-id>

=3D=3D>
  =       =  <network-access-id>LA2</network-access-id>

And = a few things are = omitted:

/l2vpn-svc/sites/site["SITE1"]/service/svc-mtu = is mandatory and not included in the example. I'd suggest adding a = default instead, the MTU is perhaps not the first thing you think about = when defining a new service. Now it has to be given = immediately.

 

/l2vpn-svc/sites/site["SITE1"]/management/type is = mandatory and not included in the example. As soon as a type is set, a = number of other things become mandatory too. Which ones depends on what = type you select.

 

/l2vpn-svc/sites/site["SITE1"]/site-network-accesses/si= te-network-access["LA1"]/vpn-attachment/vpn-id refers to a VPN = that is not defined, but I guess that's = acceptable.

 

p41:

Example broken:

 

        =  <site-network-access-id>LA1</site-network-access-id>

=3D=3D>

        =  <network-access-id>LA1</network-access-id>

 

Same things omitted as on = p39.

 

p42:

Example broken in a couple of = places:

 

1.

      =         =  <filter>

                =  <lan-tag>LAN1</lan-tag>

=3D=3D>

              =  <filter>

                =  <type>lan</type>

                =  <lan-tag>17</lan-tag>

=

 

2.

              =  <filter>

                =  <lan-tag>LAN2</lan-tag>

=3D=3D>

              =  <filter>

                =  <type>lan</type>

                =  <lan-tag>18</lan-tag>

=

 

3.

      =       = <site-network-access-id>LA1</site-network-access-id>

=3D=3D>
  =           = <network-access-id>LA1</network-access-id><= /p>

Omits = service/svc-mtu and management/type like on = p39.

 

p60:

Example broken in a number of = places:

 

1.

            = <location>
              = <city>NY</city>
            =   <country-code>US</country-code>
    =       =  </location>

=3D=3D>

      =     <locations>
          =   <location>
            =   <location-id>NY1</location-id>
    =           <city>NY</city>
  =             = <country-code>US</country-code>
      =      </location>
        =  </locations>

2.

      =         =  <site-network-access-id>CSP_A_VN1</site-network-access-id&= gt;

=3D=3D>
  =             =  <network-access-id>CSP_A_VN1</network-access-id-->=

3.

      =                 =  <eth-inf-type>tagged<eth-inf-type>

=3D=3D>
  =                     =  <eth-inf-type>tagged</eth-inf-type>

4.

      =                   =  <tagged-inf-type>dot1q-vlan</tagged-inf-type>

=3D=3D>
  =                     =   =  <tagged-inf-type>dot1q</tagged-inf-type>

5.

                  =         = <vlan-id>17</vlan-id>

=3D=3D>

                  =         = <cvlan-id>17</cvlan-id>

 

6.

Need to move = <service> out of = <site-network-accesses/>

 

7.

Missing end = tag

      =                     =  </bandwidth>

 

8.

Not making up our = mind on how to spell signaling/signalling bites = us:

 

                  =           =  <signaling-type>bgp</signaling-type><= /p>

=3D=3D>
  =                     =       =  <signalling-type>bgp</signalling-type>

Same omissions as on = p39.

 

p68a:

Example broken:

 

Some unwanted whitespace crept = in:

      =               =  <svc-type>vpws</svc -type = >

=3D=3D>

                  =   =  <svc-type>vpws</svc-type>

 

/l2vpn-svc/vpn-services/vpn-service["12456487" and = "12456488"]/frame-delivery/multicast-gp-port-mapping is = mandatory and not configured

 

p68b:

Example broken in a number of = places:

 

1.

                = <location>

                  =  <city>NY</city>

                  =  <country-code>US</country-code>

      =           = </location>

=3D=3D>

                = <locations>

                = <location>

                  = <location-id>NY1</location-id>

                  =  <city>NY</city>

                  =  <country-code>US</country-code>

      =           = </location>

                = </locations>

 

2.

Double start = tags

      =               = <access-diversity>

=3D=3D>
  =                   = </access-diversity>

3.

I'm guessing the = author means "vlan" when saying "dot1q" = ?

      =               =  <encapsulation-type>dot1q</encapsulation-type>

=3D=3D>

                  =   =  <encapsulation-type>vlan</encapsulation-type>

 

4.

Wrong end = tag

      =                 = </untagged-interface>

=3D=3D>
  =                     = </tagged-interface>

5.

Needs to be = lowercase

      =                   = <stp-rstp-mstp>TUNNEL</stp-rstp-mstp>

=3D=3D>
  =                     =   = <stp-rstp-mstp>tunnel</stp-rstp-mstp>

6.

      =                   = <lldp>TRUE</lldp>

=3D=3D>
  =                     =   <lldp>true</lldp>

7.

Need to move <service> out of = <site-network-accesses/>

 

8.

                  =     =  <signaling-type>bgp</signaling-type><= /p>

=3D=3D>
  =                     =  <signalling-type>bgp</signalling-type>

 

Same omissions as on p39.

 

 

 

Obviously, these XML fixes assume an unchanged YANG model. As = they YANG is fixed/changed, the examples should follow = suit.

 

That's all I found.

 

Thanks!

/jan

 

 

 

From: Jan Lindblad [mailto:janl@tail-f.com] 
Sent: 17 January 2018 = 11:29
To: Adrian = Farrel
Cc: bclaise@cisco.com; Qin = Wu
Subject: Re: Cheeky = request

 

Adrian,

 

You did such a good job with the L3SMbis draft that it should = come as no
surprise that we are all queueing up to have you as a = reviewer.

https://datatracker.ietf.org/doc/draft-ietf-l2sm-l= 2vpn-service-model/ is now
very close to WG = last call and we just made a request for "early" YANG = Doctor
review.

But if you were able to look at it as well, = that would be rather good. Of
course, you are allowed to be = tired/bored/busy = :-)

 

Flattery is often effective ;-) Thank you for asking. I would = certainly be interested to have a good look at all IETF service models, = and perhaps better to get into the habit of doing that before the = publication rather than after :-/ I guess it's primarily going to be a = question of when you need the answer. By when would you need = it?

 

Best Regards,

/jan

--

Jan Lindblad, janl@tail-f.com, +46 = 702855728

Solutions Architect, Business = Development, Tail-f

Tail-f is now a part of = Cisco

 

------=_NextPart_000_0B4C_01D39AA0.1FBA8A40--