Subject: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-06.txt

From: [email-masked]
Date: Mon, 02 May 2016 01:44:07 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the L3VPN Service Model  of the IETF.

        Title           : YANG Data Model for L3VPN service delivery
        Authors         : Stephane Litkowski
                          Rob Shakir
                          Luis Tomotaki
                          Kenichi Ogaki
                          Kevin D'Souza
	Filename        : draft-ietf-l3sm-l3vpn-service-model-06.txt
	Pages           : 126
	Date            : 2016-05-02

Abstract:
   This document defines a YANG data model that can be used to deliver a
   Layer 3 Provider Provisioned VPN service.  The document is limited to
   the BGP PE-based VPNs as described in RFC4110 and RFC4364.  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.  This model provides an abstracted
   view of the Layer 3 IPVPN service configuration components.  It will
   be up to a management system to take this as an input and use
   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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-l3sm-l3vpn-service-model-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-l3sm-l3vpn-service-model-06

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: Benoit Claise <[email-masked]>
Date: Tue, 3 May 2016 12:13:52 +0200

Dear authors,

FYI. http://www.claise.be/IETFYANGPageCompilation.html

You're missing a statement such as:

  revision 2016-05-02 {
         description
          "something is updated";
         reference "";
     }

https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-12#section-7.1.9

Regards, Benoit
> _______________________________________________
> L3sm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l3sm
> .
>

---

From: <[email-masked]>
Date: Tue, 3 May 2016 16:52:19 +0000

Right, will fix it in the next revision.

From: L3sm [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Tuesday, May 03, 2016 12:14
To: [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-06.txt

Dear authors,

 revision 2016-05-02 {

        description

         "something is updated";

        reference "";

    }

Regards, Benoit

                          Rob Shakir

                          Luis Tomotaki

                          Kenichi Ogaki

                          Kevin D'Souza

  Pages           : 126

  Date            : 2016-05-02

Abstract:

L3sm mailing list

[email-masked]<mailto:[email-masked]>

.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: David Ball <[email-masked]>
Date: Thu, 5 May 2016 16:32:35 +0100

Hi Stephane,

I've taken a look at the new draft - I think most of the issues I raised 
are addressed, thanks!

There are still a few points that I think could be made clearer - see 
below.  No major issues here, this is just about making the draft 
clearer for the reader.

  * Sn 2: I'm not sure that we reached consensus on the definitions of
    PE and CE.  I think the new version is better, but "SP-customer
    location boundary" is rather vague, and I still don't think the
    definitions should be tied to the location of the devices - it is
    certainly normal that the CE is at the customer premises and the PE
    is at the SP premises, but it's not a hard requirement.  The PE and
    CE are better distinguished by their function rather than their
    location.  So I suggest:
      o CE Device: Equipment that is dedicated to a particular customer
        and is directly connected (at layer 3) to one or more PE devices
        via attachment circuits.  A CE is usually located at the
        customer premises, and is usually dedicated to a single VPN,
        although it may support multiple VPNs if each one has separate
        attachment circuits.
      o PE Device: Equipment managed by the SP that can support multiple
        VPNs for different customers, and is directly connected (at
        layer 3) to one or more CE devices via attachment circuits.  A
        PE is usually located at an SP point of presence (PoP) and is
        managed by the SP.
  * Sn 5.1.1.4: As we discussed, a hub-and-spoke-disjoint VPN with 2
    hubs is exactly the same as having 2 hub-and-spoke VPNs each with a
    single hub.  I think hub-and-spoke-disjoint could be removed;
    failing that, it would be useful to add some text to point out that
    they are the same.
  * Sn 5.1.4: Need to clarify that if VPN A lists VPN B as an extranet,
    then even though there is no service configuration requirement on
    VPN B, all sites in VPN B can access all sites in VPN A.  In other
    words, listing VPN B as an extranet enables bidirectional traffic to
    and from VPN B, not just unidirectional traffic from VPN A to VPN B.
  * Sn 5.2.1.2.1: Need to clarify what parameters are assumed to be
    provided via DHCP/SLAAC (I assume at least IP address, mask, and
    default gateway)
  * Sn 5.4.1.2: As we discussed before, clarification is needed about
    how traffic received from the site is associated with the right
    VPN.  You said this is based on the destination address, so this
    needs to be mentioned in the text.  Also we either need to add a
    requirement that the same destination must not be reachable through
    two different VPNs, or we need a way to determine which VPN is used
    if the same destination is reachable through more than one of them. 
    You said there is no use case for this, so adding the requirement
    seems simpler.
  * Sn 5.5.2: It is still unclear how this applies to multi-homed
    sites.  I think the requirements need to be reworded:
      o A site belonging to the same site-group as another site MUST NOT
        have any site-network-accesses that terminate at a PE in the
        same PoP as a site-network-access for the other site, if at
        least one of the sites has diversity set to PoP-diverse.
      o A site belonging to the same site-group as another site MUST NOT
        have any site-network-accesses that terminate on the same PE as
        a site-network-access for the other site, if at least one of the
        sites has diversity set to PE-diverse
      o A site belonging to the same site-group as another site MUST NOT
        have any site-network-accesses that terminate on the same
        linecard in the same PE as a site-network-access for the other
        site, if at least one of the sites has diversity set to
        linecard-diverse.
  * Sn 5.5.2: Typo expect -> except (lots of times, in the examples).
  * Sn 5.5.3: As we discussed, the site-network-access diversity should
    be a per-site attribute, not a property of the individual network
    accesses (otherwise there is the same problem of what to do if the
    network accesses are set with different values). Setting the
    network-access-diversity for a site to PE-diverse (for example)
    means that all the network-accesses for that site must terminate on
    different PEs.  It doesn't make sense to allow different values to
    be set for different network-accesses, e.g. one network-access set
    to PE-diverse and one set to non-diverse.
  * Sn 5.5.3:  The text says that the access priority can be "used to
    model any kind of loadbalancing or primary/backup scenario."
    However, this is not true - I gave an example before of a scenario
    that cannot be modelled using this mechanism.
  * Sn 5.5.3.1: Again, this should be a per-site attribute - it makes no
    sense to enable protection on one network-access and disable it on
    another; it needs to be either enabled on all network-accesses for a
    given site, or on none of them, i.e. at a service level it is a
    per-site attribute.
  * Sn 5.6: This description refers to the bearer as L1 ("media type"
    etc) - but we discussed before that the bearer should encompass
    everything below L3, including any L2 details (VLANs, LAG, etc). 
    This was clarified in sn 5.2.1.1 but I think it needs to be
    mentioned here too.
  * Sn 5.6: I don't understand how you expect the bearer-reference to be
    used.  How does the customer know what internal reference the SP has
    allocated for a given existing connection?  Can you add an example?
  * Sn 5.8: If the CE is provider-managed, why is a management address
    needed in the model?  How the provider connects to the device would
    be internal to the provider, right?
    (For co-managed I can see this could be needed, i.e. to tell the
    customer what address to use to connect to the device for
    configuration/monitoring)
  * Sn 5.9.2: You said before that today you only manage P2P
    connections; but this figure (and the next one) show the PE
    connected to a LAN, not to a CE.  I am not sure how to interpret
    this?  Is this a case where the connection is multipoint, not P2P?
  * Sn 5.9.2, 5.9.3, 5.9.4: Need to clarify that in these cases, the
    CE/customer has a default route towards the SP (and that the gateway
    address is the same as the SP address provided in the connection
    addressing).
  * Sn 5.10.2: I am still confused about what "outgoing QoS profile"
    means here - outgoing from where?  Is the QoS profile applied to
    traffic from the customer towards the SP, or to traffic from the SP
    towards the customer?
  * Sn 5.10.2.2: Need to clarify that the rate-limit is a percentage of
    the value in svc-input-bandwidth or svc-output-bandwidth.  How does
    the SP determine which one to use?
  * Sn 5.14: Some of the examples here still show an apply-template leaf
    under the service container, which does not match the model. In the
    yang, apply-template can only be under a site or under a
    site-network-access.
  * Sn 5: You mentioned you would add some details about OAM in section 5.
  * Sn 8: The new identities for applications are missing a "base"
    clause to link them to the customer-application identity.
  * Sn 8: site-group is only useful when the site-diversity/type is not
    non-diverse - could add a "when" clause to make that explicit?
  * Sn 8: svc-mtu leaf: you were going to clarify that in the CsC case,
    the MTU value includes the MPLS labels.

Thanks,

     David

-- 
David Ball
<[email-masked]>