[L2sm] R: Alissa Cooper's Discuss on draft-ietf-l2sm-l2vpn-service-model-09: (with DISCUSS and COMMENT)

Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it> Fri, 06 April 2018 08:03 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 748A512D7EC; Fri, 6 Apr 2018 01:03:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id q2Yftsg3s-F9; Fri, 6 Apr 2018 01:03:05 -0700 (PDT)
Received: from mx02.telecomitalia.it (mx02.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 C2BD4128961; Fri, 6 Apr 2018 01:03:03 -0700 (PDT)
X-AuditID: d9a97916-d73ff70000003a07-50-5ac729b5da2d
Received: from TELMBXB02RM001.telecomitalia.local ( []) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id C6.1C.14855.5B927CA5; Fri, 6 Apr 2018 10:03:01 +0200 (CEST)
From: Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it>
To: Alissa Cooper <alissa@cooperw.in>
CC: IESG <iesg@ietf.org>, "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>, "l2sm@ietf.org" <l2sm@ietf.org>
Thread-Topic: Alissa Cooper's Discuss on draft-ietf-l2sm-l2vpn-service-model-09: (with DISCUSS and COMMENT)
Thread-Index: AQHTzDwhi0nmL6VRfUmP7KBZUnW2CKPx34KQgABdc4CAARQrkA==
Date: Fri, 6 Apr 2018 08:03:01 +0000
Message-ID: <9941c43fbc234c7c9ab1b0e924efa369@TELMBXB02RM001.telecomitalia.local>
References: <152286367177.24002.11481064509507744096.idtracker@ietfa.amsl.com> <6953decf568b4e15bf205de75964d00e@TELMBXB02RM001.telecomitalia.local> <365839B3-B091-4918-A106-4510DAC176C0@cooperw.in>
In-Reply-To: <365839B3-B091-4918-A106-4510DAC176C0@cooperw.in>
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: multipart/alternative; boundary="_000_9941c43fbc234c7c9ab1b0e924efa369TELMBXB02RM001telecomit_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsXCxfdHWner5vEogzv/jCx+9Nxgtph+5i+j Rc/jRiaLGX8mMls82HmRzeLOy5eMDmweX568ZPJYsuQnk8eKzSsZA5ijuGxSUnMyy1KL9O0S uDI+X9/OWDBtKlPF9UVL2BoYv/QydTFyckgImEgcmDCHpYuRi0NIYCqTxNyue2wgCTYBG4mD r06A2SICqhJXj/0As5kFPjFKHG8tBrGFBbIl3n5+yAhRkyux9Mtr1i5GDiDbSeJhryxImEVA RWLJnE1gu3gFAiV6lp2B2nWKUWL278vMIAlOATuJ/tXzWUFsRgFZiQm7FzFC7BKXeDH9BDvE oQISS/acZ4awRSVePv7HCmEbSGxduo8FwlaUmHTqKVRcRmLhkclg9zAL5Essf6MDcYOgxMmZ T1gmMIrOQrJhFkLVLCRVEGFNifW79CGqFSWmdD9kh7A1JFrnzGVHFl/AyL6KUTS3wsBIryQ1 JzU5PzezJDEnM1Evs2QTIzA+b66sFNvB2LrW+RCjAAejEg/vftHjUUKsiWXFlbmHGCU4mJVE eHf/ORYlxJuSWFmVWpQfX1Sak1p8iFGag0VJnFddFSglkJ5YkpqdmlqQWgSTZeLglGpgVJGX bivWP5CdcvmtJItCZ+q595nBPUubtLzniv8v01DKPNUfF/f2WJYPd6HK1ukBTrX8W0MuruHO +c3DsMh5Te2FdBvvrPUzatI9LSuLTsWWFPkq51ckpz+79X6Dy7MgS86cix+i33V4n1p36U3T J0HWH30OC3e0c66bVyMWXD/dz/pSEKcSS3FGoqEWc1FxIgBU9uqaywIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/rcbAsJuifx3VxlPcxSD3o8IOrcY>
Subject: [L2sm] R: Alissa Cooper's Discuss on draft-ietf-l2sm-l2vpn-service-model-09: (with DISCUSS and 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: Fri, 06 Apr 2018 08:03:11 -0000

Hi Alissa,
My answers inline tagged as [GF].



Da: Alissa Cooper [mailto:alissa@cooperw.in]
Inviato: giovedì 5 aprile 2018 18:31
A: Fioccola Giuseppe
Cc: IESG; draft-ietf-l2sm-l2vpn-service-model@ietf.org; Adrian Farrel; l2sm-chairs@ietf.org; l2sm@ietf.org
Oggetto: Re: Alissa Cooper's Discuss on draft-ietf-l2sm-l2vpn-service-model-09: (with DISCUSS and COMMENT)

Hi Giuseppe,

On Apr 5, 2018, at 5:36 AM, Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it<mailto:giuseppe.fioccola@telecomitalia.it>> wrote:

Hi Alissa,
Thank you for the comments and for bringing out good points.
Answers inline tagged as [GF].

Best Regards,


-----Messaggio originale-----
Da: Alissa Cooper [mailto:alissa@cooperw.in]
Inviato: mercoledì 4 aprile 2018 19:41
Cc: draft-ietf-l2sm-l2vpn-service-model@ietf.org<mailto:draft-ietf-l2sm-l2vpn-service-model@ietf.org>; Adrian Farrel; l2sm-chairs@ietf.org<mailto:l2sm-chairs@ietf.org>; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; l2sm@ietf.org<mailto:l2sm@ietf.org>
Oggetto: Alissa Cooper's Discuss on draft-ietf-l2sm-l2vpn-service-model-09: (with DISCUSS and COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-l2sm-l2vpn-service-model-09: Discuss

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:


Sec 5.2 says:

"Cloud Access (cloud-access):  All sites in the L2VPN MUST be
     authorized to access to the cloud.  The cloud-access container
     provides parameters for authorization rules.  A cloud identifier
     is used to reference the target service.  Th"

But Sec 5.2.3 says:

"By default, all sites in the L2VPN SHOULD be authorized to access the
  cloud.  If restrictions are required, a user MAY configure the
  "permit-site" or "deny-site" leaf-list.  The permit-site leaf-list
  defines the list of sites authorized for cloud access.  The deny-site
  leaf-list defines the list of sites denied for cloud access.  The
  model supports both "deny-any-except" and "permit-any-except"

These seem to be conflicting normative requirements. At a minimum, they need to be aligned (presumably to the formulation in 5.2.3, given the existence of permit-site and deny-site). But more generally, why does the model need to normatively require nodes to have a certain kind of access? As the Gen-ART reviewer pointed out, this doesn't seem necessary. And given that the cloud-access configuration requires the specification of a specific cloud-access identifier, what does it even mean that nodes should be authorized to access "the" cloud?

[GF]: Yes, this is an oversight and we can keep the formulation aligned with 5.2.3. Our intention is to specify the cloud identifier instead of cloud access identifier,

I’m not following what the difference is between these two.

[GF]: I was just trying to say that cloud identifier is only the cloud name or internet service name. Instead cloud access parameters can be applied to cloud identifiers to set the rules.

cloud identifier is only referred to public cloud name or internet service name. Cloud access is not part of VPN service, therefore we specify cloud access to allow VPN to extend its footprint to public cloud or internet. By default, we allow all sites within one L2VPN to get access to one cloud or internet, but in some cases, we may limit nodes in some sites to get access to one cloud or internet.

Thanks. I think if you could provide a short explanation in the document of why the default is what it is, that would help as well.

[GF]: Of course, we will do. We can also clarify how cloud access parameters can be used to generate network access policy on nodes within each sites to limit access to public cloud or public internet.


This can be done by defining network access policy on nodes within a site.


This comment from the Gen-ART reviewer has not been addressed and I think it should be: "I would have expected some reference to the MEF Ethernet service
  definitions and MEF defined parameters of interest, as industry usage seems
  to reflect those as the common basis for L2 services.  I udnerstand that
  this model is not mandated to conform to the MEF Forum work.  I would
  expect some discussion of the relationship."

[GF]: Yes, we should add some more specific statement to explain better the MEF relationship. Please refer also to section 5.2.1:
  Other L2VPN Service Types could be included by augmentation.  Note
  that an Ethernet Private Line (EPL) service or an Ethernet Virtual
  Private Line (EVPL) service is an E-Line service or a point-to-point
  Ethernet Virtual Circuit (EVC) service, while an Ethernet Private LAN
  (EP-LAN) service or an Ethernet Virtual Private LAN (EVP-LAN) service
  is an E-LAN service or a multipoint-to-multipoint EVC service.
[GF]: I think MEF defined service can be mapped to IETF defined VPN service type. We can also refer to RFC8309 section 6.4 to get the sense of difference.

Sec 5.2.3:

"The usage of cloud-access is targeted for public
  cloud and for Internet access.


From the perspective of the output of the IETF overall, the above
gives me pause. The notion that the Internet is just one cloud among many seems out of sync with how we would typically talk about the Internet in the IETF, and with RFC 4084 (and perhaps RFC 1958). I realize this is basically a labeling issue, but if the cloud-access element stays in the model, would it be possible to use a different label for configuration of Internet service other than "cloud-access"? This potentially gets back to the point from the Gen-ART reviewer about the necessity of having these different identifiers not being obvious.

[GF]:  Understand. We considered that public cloud and public internet access share some commonality, therefore we don't distinguish Internet access from cloud access. Yes, it is possible to define a separated label for Internet service to be coherent with IETF RFCs.

Sec 8:

Regarding the location element, if you want the address information to be usable globally (which presumably you do), you will want to consider profiling the address elements in RFC 4119 and/or RFC 5139. At a minimum, jurisdiction-specific identifiers like ZIP code, which only exist in the US, should be replaced by generic address field types.

[GF]: Agree. We will fix it.


Sec 5.15:


Sec 5.10.3:


[GF]: Ok, will fix them.

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.