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

[Fioccola Giuseppe <[e-mail]>]

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]] 
Inviato: mercoledì 4 aprile 2018 19:41
A: The IESG
Cc: [e-mail]; Adrian Farrel; [e-mail]; [e-mail]; [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, 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. 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.