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

[Alissa Cooper <[e-mail]>]

Hi Giuseppe,

> On Apr 5, 2018, at 5:36 AM, Fioccola Giuseppe <[e-mail]> wrote:
> 
> Hi Alissa,
> Thank you for the comments and for bringing out good points.
> Answers inline tagged as [GF].
> 
> Best Regards,
> 
> Giuseppe
> 
> -----Messaggio originale-----
> Da: Alissa Cooper [mailto:[e-mail] <mailto:[e-mail]>] 
> Inviato: mercoledì 4 aprile 2018 19:41
> A: The IESG
> Cc: [e-mail] <mailto:[e-mail]>; Adrian Farrel; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 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"
>   authorization."
> 
> 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.

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

Alissa

> This can be done by defining network access policy on nodes within a site.
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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.
>   ...
> 
>   <cloud-accesses>
>       <cloud-access>
>          <cloud-identifier>INTERNET</cloud-identifier>
>       </cloud-access>
>      </cloud-accesses>"
> 
>> From the perspective of the output of the IETF overall, the above 
>> phrasing
> 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.
> 
> Nits:
> 
> Sec 5.15:
> 
> s/remote-carrrier-name/remote-carrier-name/
> 
> Sec 5.10.3:
> 
> s/broadcast-unknowunicast-multicast/broadcast-unknown-unicast-multicast/
> 
> [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.