[L2sm] R: Benjamin Kaduk's No Objection on draft-ietf-l2sm-l2vpn-service-model-09: (with COMMENT)

Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it> Thu, 05 April 2018 14:46 UTC

Return-Path: <giuseppe.fioccola@telecomitalia.it>
X-Original-To: l2sm@ietfa.amsl.com
Delivered-To: l2sm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5AAF612D7F9; Thu, 5 Apr 2018 07:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mnjFMEGSTnj4; Thu, 5 Apr 2018 07:46:33 -0700 (PDT)
Received: from mx03.telecomitalia.it (mx03.telecomitalia.it []) (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 776651275AB; Thu, 5 Apr 2018 07:46:32 -0700 (PDT)
X-AuditID: d9a97917-09fff70000000db8-a4-5ac636c6b0ad
Received: from TELMBXB02RM001.telecomitalia.local ( []) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx03.telecomitalia.it () with SMTP id 74.94.03512.6C636CA5; Thu, 5 Apr 2018 16:46:30 +0200 (CEST)
From: Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-l2sm-l2vpn-service-model@ietf.org" <draft-ietf-l2sm-l2vpn-service-model@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, "l2sm-chairs@ietf.org" <l2sm-chairs@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "l2sm@ietf.org" <l2sm@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-l2sm-l2vpn-service-model-09: (with COMMENT)
Thread-Index: AQHTzE3ppw81j4B2nESuqqerq3IJAKPyNDbg
Date: Thu, 5 Apr 2018 14:46:30 +0000
Message-ID: <12f3fba7302e43d1acc2edf6706426a4@TELMBXB02RM001.telecomitalia.local>
References: <152287130759.23972.4894092819553843074.idtracker@ietfa.amsl.com>
In-Reply-To: <152287130759.23972.4894092819553843074.idtracker@ietfa.amsl.com>
Accept-Language: it-IT, en-US
Content-Language: it-IT
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-ti-disclaimer: Disclaimer1
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGKsWRmVeSWpSXmKPExsXCxfdHWveY2bEog4eHlS1+9Nxgtuh53Mhk MePPRGaL5RtnMlk82HmRzeLOy5eMDmweS5b8ZPJoOnOU2WPF5pWMAcxRDYw2iXl5+SWJJakK KanFybZKLpnFyTmJmbmpRQohqTmpyfm5SgqZKbZKxkoKBTmJyam5qXkltkqJBQWpeSlKdlwK GMAGqCwzTyE1Lzk/JTMv3VbJM9hf18LC1FLXUMkusDS1uCRfITe1uDgxPT0zXyE1Yb1gxpFz bAWzLCr+HXrJ3sD4wKyLkZNDQsBEoqt5JmMXIxeHkMBUJom3l9aygSTYBGwkDr46AWaLANmL 7+5lBrGZBTqZJLp7dUFsYYFUiffXJrFC1KRL3P1ylBnCNpJ4uec9WC+LgIrErDuXweK8AoES 97qmMoHYQgK+Eq9W/QSKc3BwCvhJLD1vAxJmFJCVmLB7ESPEKnGJF9NPsEPcKSCxZM95Zghb VOLl43+sELaBxNal+1ggbEWJSaeeQsVlJBYemcwKMp5ZQFNi/S59iJGKElO6H7JDXCMocXLm E5YJjGKzkGybhdAxC0nHLCQdCxhZVjGK5lYYGOuVQOIusyQxJzNRL7NkEyMwsdxcWSm+g7F9 pfMhRgEORiUe3l2yx6KEWBPLiitzDzFKcDArifBGaAGFeFMSK6tSi/Lji0pzUosPMfoAg2si s5Rocj4w6eWVxBuaWFgaGltYGBlamJniEFYS51VXBZolkA5MXNmpqQWpRTDjmDg4pRoYT/2U dNwQ4thqx+epfUT/mqZ13dq2ixY35q2doTslcYGCVHKWmG/J1aX3N2l7nN1q/fNp7BeuihfH +SPPOVYt5d3ZOlNivtkM2TWWfF51c9a94NxW1r5uU7eU6MIn8Vv8m/cJH9czqF3v2cpRbHO0 ZOU1/97k81Elr9mOvivmTvte0PdmbewdJZbijERDLeai4kQAGPh8NVkDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/plUS5JmuuconyEPwOLMsDZ0nrX4>
Subject: [L2sm] R: Benjamin Kaduk's No Objection on draft-ietf-l2sm-l2vpn-service-model-09: (with COMMENT)
X-BeenThere: l2sm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <l2sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2sm>, <mailto:l2sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2sm/>
List-Post: <mailto:l2sm@ietf.org>
List-Help: <mailto:l2sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2sm>, <mailto:l2sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 14:46:36 -0000

Hi Benjamin,
Thanks for your comments.
My answers inline tagged as [GF]

Best Regards,


-----Messaggio originale-----
Da: Benjamin Kaduk [mailto:kaduk@mit.edu] 
Inviato: mercoledì 4 aprile 2018 21:48
Cc: draft-ietf-l2sm-l2vpn-service-model@ietf.org; Adrian Farrel; l2sm-chairs@ietf.org; adrian@olddog.co.uk; l2sm@ietf.org
Oggetto: Benjamin Kaduk's No Objection on draft-ietf-l2sm-l2vpn-service-model-09: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-l2sm-l2vpn-service-model-09: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I support Alissa's DISCUSS.

Please be consistent about BUM vs. B-U-M and what it expands to.  (This is probably a symptom of a more general issue for documents this long with multiple contributors, where it's easy to lose a common editorial style.)  NNI and potentially other acronyms should be expanded, as well.

[GF]: Ok, we will fix it.

In Section 1

   This version of L2VPN service model supports the Network Management
   Datastore Architecture (NMDA) [I-D.ietf-netmod-revised-datastores].

is ambiguous, being readable either as "NMDA is an optional features of this version of (the) L2VPM service model" or "(the) L2VPN service model works in support of the NMDA".

[GF]: Agree, we will change the sentence according to your suggestion.

Section 5.3.2

   This site-network-access type may have an impact on the parameters
   offered to the customer, e.g., an SP might not offer encryption for
   multipoint accesses

I'm reluctant to document in 2018 something as a "VPN" that does not offer encryption, given the term's slight redefinition in the public's eye.  Maybe a different example could be used?

[GF]: Yes, we have to change or remove the example.

Section 5.6.4

   For an already-configured site-network-access, each constraint MUST
   be expressed against a targeted set of site-network-accesses.  This
   site-network-access MUST never be taken into account in the targeted
   set -- for example, "My site-network-access S must not be connected
   on the same POP as the site-network-accesses that are part of Group

I'm confused by this statement.  Possibly just by the pronoun "This site-network-access", but maybe more.

[GF]: You are right, this sentence can confuse and will be rephrased or omitted. It means that the considered site-network-access cannot be part of the targeted set of site-network-accesses against which the constraint is applied.

Section 5.10.3

   The whole Layer-2 multicast frame (whether for data or control)
   SHOULD NOT be altered from CE to CEs except that the VLAN ID field
   may be modified, ensuring that it is transparently transported.  If
   VLAN IDs are assigned by the SP, they can also be altered.

I assume that "from CE to CEs" means when spanning the SP network, right?

But I'm still confused by the "SHOULD NOT ... except that the VLAN ID field" combined with "If VLAN IDs are...they can also be altered".  Is this redundant or in need of rephrasing, or am I misreading something?

[GF]: Yes we should explain better this sentence. Only If the VLAN ID field is transparently transported, it can be altered by the CE.

In Section 5.16, why would someone pick option A, B, or C over the others -- in which case(s) are they better or worse?

[GF]: It depends because VPNs need to span different ASes in different geographic areas or span different Service Provider networks. This can be considered out of scope here because the multiple flavors are detailed in RFC4761. 

In the security considerations (Section 9), I see the standard YANG boilerplate is in use. In some ways this document's use of YANG is non-standard, though, since it's instantiated at a management system and not used for configuration directly.  So I'd be open to modifying the boilerplate if that seems appropriate.

[GF]: You are right and this is possible with extensions via augmentation.

The document also covers situations where shared tenancy is possible, both on hardware and on links. Do we want to list some of the potential risks of such shared tenancy in the security considerations, or is that too far afield?

[GF]: Agree, one more sentence will be added.

One last note on the security considerations -- are sections 5.12 and 5.13 really the only points for extension via augmentation?  Perhaps I misunderstand the intended semantics of the statement.

[GF]: The model defined in this document implements many features and augmentation but, regarding the security aspects, Section 5.12 and 5.13 are more relevant.  

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.