Subject: [L3sm] AD review of draft-ietf-l3sm-l3vpn-service-model

From: Benoit Claise <[email-masked]>
Date: Thu, 22 Sep 2016 21:27:56 +0200

Dear authors,

Many thanks to this group of operators for this YANG data for L3VPN 
service delivery, and for Stephane for the heavy lifting.

Here is my AD review.

1. CE-PE OAM
I was wondering why BFD is mentioned in a service model, but it could be 
fine I guess in case of unmanaged CE. Anyway it's optional.
Now, why I wonder why only BFD?

                   |  +--rw oam
                   |     +--rw bfd {bfd}?
                   |        +--rw bfd-enabled?    boolean
                   |        +--rw (holdtime)?
                   |           +--:(profile)
                   |           |  +--rw profile-name?   string
                   |           +--:(fixed)
                   |              +--rw fixed-value?    uint32

A few words of reference to LIME in section 5.2.2.2.2 would be welcome, 
in case we need to augment the OAM container.

2. QoS Classification
I see match statements like in the ACL YANG model in NETMOD, I see QoS 
parameters, and I wonder if it makes sense to have so many details in a 
service model. Are you really sure that you don't have too much in that 
area? Don't you need just need a very generic mechanism such as the 
tc-latency, tc-jitter, tc-bandwidth, tc-path-diversity, and 
tc-site-diversity for gold, silver and bronze?

3. YANG 1.0 or 1.1?
The write up, 
https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/shepherdwriteup/, 
mentions:

    Only one minor issue that was found is that the reference to RFC6020 should be replaced
    by RFC 7950 since YANG has been proposed to be used for RESTCONF and YANG version 1.1,
    i.e.,RFC7950 can be used to well support RESTCONF.

You don't use any YANG 1.1 features, so it's fine to refer to RFC6020

4.
The tree diagram looks scary/complex. However, there are a lot of 
optional parts (a lot of features)

     feature cloud-access {
         description
          "Allow VPN to connect to a Cloud Service
          provider.";
     }
     feature multicast {
         description
         "Enables multicast capabilities in a VPN";
     }
     feature ipv4 {
         description
         "Enables IPv4 support in a VPN";
     }
     feature ipv6 {
         description
         "Enables IPv6 support in a VPN";
     }
     feature carrierscarrier {
         description
         "Enables support of carrier's carrier";
     }
     feature traffic-engineering {
         description
         "Enables support of transport constraint.";
     }
     feature traffic-engineering-multicast {
         description
         "Enables support of transport constraint
         for multicast.";
     }
     feature extranet-vpn {
         description
         "Enables support of extranet VPNs";
     }
     feature site-diversity {
         description
         "Enables support of site diversity constraints";
     }
     feature encryption {
         description
         "Enables support of encryption";
     }
     feature qos {
         description
         "Enables support of Class of Services";
     }
     feature qos-custom {
         description
         "Enables support of custom qos profile";
     }
     feature rtg-bgp {
         description
         "Enables support of BGP routing protocol.";
     }
     feature rtg-rip {
         description
         "Enables support of RIP routing protocol.";
     }
     feature rtg-ospf {
         description
         "Enables support of OSPF routing protocol.";
     }
     feature rtg-ospf-sham-link {
         description
         "Enables support of OSPF sham-links.";
     }
     feature rtg-vrrp {
         description
         "Enables support of VRRP routing protocol.";
     }
     feature fast-reroute {
         description
         "Enables support of Fast Reroute.";
     }
     feature bfd {
         description
         "Enables support of BFD.";
     }
     feature always-on {
         description
         "Enables support for always-on access
         constraint.";
     }
     feature requested-type {
         description
         "Enables support for requested-type access
         constraint.";
     }
     feature bearer-reference {
         description
         "Enables support for bearer-reference access
         constraint.";
     }

You might want to say a few words upfront regarding these optional 
parts, e.g. the modularity aspects of this service model.

5.  Regarding the YANG model, as Lada noted for a recent review:
Adding a new "revision" statement for every I-D revision becomes 
unwieldy. RFC 6087 permits to use just one "revision" statement 
throughout the I-D stage, and just bump the revision date in its 
argument each time after the module was changed. To keep track of the 
changes in the I-D stage, it is better to have a change log section in 
the I-D that will get removed just before the document becomes an RFC.

EDITORIAL:
- I would rename "topology" to "VPN service topology" throughout the 
document, and potentially the leaf in the YANG module as well, if not 
too late.
Reasoning: this YANG model might be extended/mapped to the I2RS topology 
in a orchestrator/controller
The leaf description says "VPN technology" anyway
leaf topology { type identityref { base vpn-topology; } default 
"any-to-any"; description "VPN topology."; }
- Minor YANG issue
http://www.claise.be/IETFYANGPageCompilation.html
[email-masked]:1: warning: unexpected latest revision 
"2016-09-13" in [email-masked], should be 2016-09-15
- NetConf => NETCONF. Please add reference to [RFC6241] to the first 
instance
- RestConf => RESTCONF. Please add an informal reference to 
draft-ietf-netconf-restconf-16 
<https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/> to the 
first instance
- section 5:
"The YANG module is divided in three main containers : vpn-services, sites."
     => should be two containers.

Regards, Benoit (OPS AD)

---

From: Qin Wu <[email-masked]>
Date: Fri, 23 Sep 2016 02:10:55 +0000

Hi, authors:
I did a review of draft-ietf-l3sm-l3vpn-service-model-15 as part of the process of doing a shepherd write-up for this document. I have a number of editorial and minor comments which I would like to see being addressed along with AD review as well. Sorry for late posting.
Major issues: None
Minor issues:
1.we used a lot of "transport protocol" in the draft, but traditionally, transport protocol Is referred to TCP, UDP rather than IPv4 protocol, IPv6 protocol. This may cause some transport area people to confuse.

2.rig-ng has been clarified not needed and the rip-ng identity has been removed from routing-protocol-type, but rip-ng still appear in the section 5.10.5.
I think this needs to be cleaned up.
3.In Section 5.11.2.2, it said:
"
The REAL_TIME traffic will be rate-limit to 30% of the service bandwidth
   (30% of 100Mbps = 30Mbps) to let some place for data traffic.
"
I think Site 2 has global service bandwidth 200Mbps instead of 100Mbps? So 30% of the service bandwidth is 30% of 200Mbps=60Mbps

4.Section 12.1
The reference to RFC6020 can be replaced by RFC 7950 since YANG has been proposed to be used for RESTCONF and YANG version 1.1, i.e.,RFC7950 can be used to well support RESTCONF.

5.ID-Nits Checking
one minor Nits was found in this document is:
"
  ** There are 31 instances of too long lines in the document, the longest
     one being 13 characters in excess of 72.
"

6.BESS is now working on YANG Data Model for BGP/MPLS L3VPNs, I believe we should distinct L3SM service model from BESS L3VPN Network model, suggest to make the following changes to abstract and introduction:
Abstract:
OLD TEXT:
"
This document defines a YANG data model that can be used to deliver
   a Layer 3 Provider Provisioned VPN service.
"
NEW TEXT:
"
This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 Provider Provisioned VPN service.
"
Introduction section, 1st paragraph:
OLD TEXT:
"
This document defines a YANG data model for Layer 3 IPVPN service
   configuration.
"
NEW TEXT:
"
This document defines a YANG data model for communication between customers and network operators, and to provide input to automated control and configuration applications.
"
Section 4, 1st paragraph:
OLD TEXT:
"
The idea of the L3 IPVPN service model is to propose an abstracted
   interface to manage configuration of components of a L3VPN service.

"
NEW TEXT:
"
The idea of the L3 IPVPN service model is to propose an abstracted
   interface between customers and network operators to manage configuration of components of a L3VPN service.

"

Nits/editorial comments:
1.Section 2, PE-based VPNs bullet
This paragraph needs a reference so that PE-based VPNs can be understood, RFC4026

2.Section 5, 1st paragraph
It says:
"The YANG module is divided in three main containers : vpn-services,
   sites.
"
I only see two main containers in this sentence. s/three/two
3.      Section 5.1.1.1, 1st paragraph
OLD TEXT:
"
   It is expected management system to allocate
   automatically set of route-targets upon a VPN service creation
   request.  How management system allocates route-targets is out of
   scope of the document but multiple ways could be envisaged as
   described below.
"
NEW TEXT:
"
   It is expected the management system to allocate
   automatically a set of route-targets upon a VPN service creation
   request.  How the management system allocates route-targets is out of
   scope of the document but multiple ways could be envisaged as
   described below.
"
4.Section 5.1.1.2
"
It is expected that the management
   system that owns a any to any IPVPN service request through this
   model, needs to assign and then configure the VRF and route-targets
   on the appropriate PEs.
"
Owns a any to any IPVN service request or receive a any to any IPVPN service request?
The same comment is applied to section 5.1.1.3 and section 5.1.1.4.

5.Section 5.1.1.3, 1st paragraph
"
In the hub and spoke topology, all spoke sites can discuss only with
Hub sites but not between each other.  Hubs can discuss also between
each other.
"
I think the second sentence should be in the same context as the first sentence, i.e., “in the hub and spoke topology”, therefore I suggest:
NEW TEXT:
"
In the hub and spoke topology, all spoke sites can discuss only with
   Hub sites but not between each other, and Hubs can discuss also between
   each other.
"
6.Section 5.1.1.4, 1st paragraph:
"
In the hub and spoke disjoint topology, all spoke sites can discuss
   only with Hub sites but not between each other. Hubs cannot discuss
   between each other.
"
Same as the previous comment, suggest the following change:
NEW TEXT:
"
In the hub and spoke disjoint topology, all spoke sites can discuss
   only with Hub sites but not between each other, and Hubs cannot discuss
   between each other.
"
7.Section 5.1.2, 8th paragraph:
"
Defining both denied-sites and authorized-sites MUST be processed as
   "deny all except", so the denied-sites will have not effect.
“
s/have not effect/have no effect

8.Section 5.1.3
"
The
   proposed model supports ASM, SSM and BiDirectional trees (and can be
   augmented).
"
is there any reference to Bidirectional tree?
9.Section 5.1.3, last paragraph:
"
By default, model considers static-rp if
   ASM is requested.
"
s/by default, model/by default, the model
10.   Section 5.2
s/site location informations/site location information
11.   Section 5.3
"As a consequence, each site belonging to a VPN as a particular role in
this topology."
s/as/is assigned with
12.   Section 5.4.1.3
"
It is similar than having separate sites instead that the customer
   wants to share some physical components while keeping strong
   isolation.
"
similar than having or similar to have? Keeping strong isolation for communication?
13.   Section 5.4.1.14
"
Using the site container to model
NNI is only one the possible option for NNI (see Section 5.14).
"
s/ only one the possible option/ only one possible option
14.   Section 5.4.2.2
"
we must precise its role (site-
   role) within the targeted VPN topology.

"
s/precise/precisely describe
15.   Section 5.5
"
The management system SHOULD honor the customer constraints, if the
   constraint cannot be filled, the management system MUST not provision
   the site and SHOULD provide an information to the user.  How the
   information is provided is out of scope of the document.  It would
   then be up to the user to relax the constraint or not. Parameters are
just hints for management system for service
   placement.
"
The first sentence says:
"if the constraint cannot be filled, the management system MUST not provision the site"
The third sentence says:
"The would then be up to the user to relax the constraint or not”, to make these two sentences consistent, suggest to change the first sentence as:
"
if the constraint is too strict and can not be filled, the management system MUST not provision the site
"
16.   Section 5.5.4, the first paragraph and 2nd paragraph
s/By, default/by default,
s/ accomodate /accommodate
17.   Section 5.2.2
s/is splitted in/is split into
18.   Section 5.5.7
s/ management system/ the management system
19.   Section 5.6
s/At the contrary/On the contrary
20.   section 5.10.7
"
The service configuration below actives BGP on PE-CE link for both
   IPv4 and IPv6.

"
s/actives/activates
21.   Section 5.11.1
OLD TEXT
"
It can also be used to rate-limit in a different way
   upload and download on a symmetric bandwidth access.

"
NEW TEXT:
"
It can also be used to set rate-limit in a different way
   for upload and download on a symmetric bandwidth access.

"
22.   Section 5.11.1, 3rd paragraph
s/ primarly/ primarily
23.   Section 5.11.2.1
s/ wille/will

24.   Section 5.5.3
s/ fullfilled/fulfilled
25.   Section 5.12.2, 1st paragraph, the first 4 bullets:
s/allow/allows
26.   Section 5.14
OLD TEXT:
"
In an Inter-AS Option A, ASBR peers
   are connected by multiple interfaces with at least one interface VPN
   that spans the two autonomous systems
"
NEW TEXT:
"
In an Inter-AS Option A, ASBR peers
   are connected by multiple interfaces with at least one interface which VPN spans the two autonomous systems
"
Thanks!
-Qin (Document Shepherd)
发件人: L3sm [mailto:[email-masked]] 代表 Benoit Claise
发送时间: 2016年9月23日 3:28
收件人: [email-masked]
主题: [L3sm] AD review of draft-ietf-l3sm-l3vpn-service-model

Dear authors,

Many thanks to this group of operators for this YANG data for L3VPN service delivery, and for Stephane for the heavy lifting.

Here is my AD review.

1. CE-PE OAM
I was wondering why BFD is mentioned in a service model, but it could be fine I guess in case of unmanaged CE. Anyway it's optional.
Now, why I wonder why only BFD?

                  |  +--rw oam

                  |     +--rw bfd {bfd}?

                  |        +--rw (holdtime)?

                  |           +--:(profile)

                  |           +--:(fixed)

A few words of reference to LIME in section 5.2.2.2.2 would be welcome, in case we need to augment the OAM container.

2. QoS Classification
I see match statements like in the ACL YANG model in NETMOD, I see QoS parameters, and I wonder if it makes sense to have so many details in a service model. Are you really sure that you don't have too much in that area? Don't you need just need a very generic mechanism such as the tc-latency, tc-jitter, tc-bandwidth, tc-path-diversity, and tc-site-diversity for gold, silver and bronze?

3. YANG 1.0 or 1.1?
The write up, https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/shepherdwriteup/, mentions:

4.
The tree diagram looks scary/complex. However, there are a lot of optional parts (a lot of features)

    feature cloud-access {

        description

         provider.";

    }

    feature multicast {

        description

    }

    feature ipv4 {

        description

    }

    feature ipv6 {

        description

    }

        description

    }

        description

    }

        description

        for multicast.";

    }

    feature extranet-vpn {

        description

    }

    feature site-diversity {

        description

    }

    feature encryption {

        description

    }

    feature qos {

        description

    }

    feature qos-custom {

        description

    }

    feature rtg-bgp {

        description

    }

    feature rtg-rip {

        description

    }

    feature rtg-ospf {

        description

    }

        description

    }

    feature rtg-vrrp {

        description

    }

    feature fast-reroute {

        description

    }

    feature bfd {

        description

    }

    feature always-on {

        description

        constraint.";

    }

    feature requested-type {

        description

        constraint.";

    }

        description

        constraint.";

    }
You might want to say a few words upfront regarding these optional parts, e.g. the modularity aspects of this service model.

5.  Regarding the YANG model, as Lada noted for a recent review:
Adding a new "revision" statement for every I-D revision becomes unwieldy. RFC 6087 permits to use just one "revision" statement throughout the I-D stage, and just bump the revision date in its argument each time after the module was changed. To keep track of the changes in the I-D stage, it is better to have a change log section in the I-D that will get removed just before the document becomes an RFC.

EDITORIAL:
- I would rename "topology" to "VPN service topology" throughout the document, and potentially the leaf in the YANG module as well, if not too late.
Reasoning: this YANG model might be extended/mapped to the I2RS topology in a orchestrator/controller
The leaf description says "VPN technology" anyway
leaf topology { type identityref { base vpn-topology; } default "any-to-any"; description "VPN topology."; }
- Minor YANG issue
http://www.claise.be/IETFYANGPageCompilation.html
[email-masked]:1<mailto:[email-masked]:1>: warning: unexpected latest revision "2016-09-13" in [email-masked]<mailto:[email-masked]>, should be 2016-09-15
- NetConf => NETCONF. Please add reference to [RFC6241] to the first instance
- RestConf => RESTCONF. Please add an informal reference to draft-ietf-netconf-restconf-16<https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/> to the first instance
- section 5:
"The YANG module is divided in three main containers : vpn-services, sites."
    => should be two containers.

Regards, Benoit (OPS AD)

---

From: <[email-masked]>
Date: Fri, 23 Sep 2016 13:27:50 +0000

Hi Benoit,

We will take care of your comments asap with a new I-D revision.
Some comments inline.

Brgds,

Stephane

From: L3sm [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Thursday, September 22, 2016 21:28
To: [email-masked]
Subject: [L3sm] AD review of draft-ietf-l3sm-l3vpn-service-model

Dear authors,

Here is my AD review.

1. CE-PE OAM

                  |  +--rw oam

                  |     +--rw bfd {bfd}?

                  |        +--rw (holdtime)?

                  |           +--:(profile)

                  |           +--:(fixed)

[SLI] When discussed, BFD was the most (only ?) used protocol today, that’s why we added it, but nothing prevents augmenting with others.

[SLI] Ok

2. QoS Classification

[SLI] This point was discussed when we wrote the QoS parts. Some customers are using flexible QoS models where we gave the ability for them to define their own profile (not completely but a lot of tunable parameters). So the scheduling model supports both well known profiles (gold, silver, bronze …) as well as flexible model.
For classification, there is no choice, customer need to provide inputs for its classification, so must define its flows … it can define it in a abstracted manner (by applications) or again using a flexible policy model when the application is not an existing one.

3. YANG 1.0 or 1.1?

[SLI] I was wondering if I could start using some YANG 1.1 features, for example using “feature” for identities.
Anyway I can replace the reference with YANG 1.1.

4.

    feature cloud-access {

        description

         provider.";

    }

    feature multicast {

        description

    }

    feature ipv4 {

        description

    }

    feature ipv6 {

        description

    }

        description

    }

        description

    }

        description

        for multicast.";

    }

    feature extranet-vpn {

        description

    }

    feature site-diversity {

        description

    }

    feature encryption {

        description

    }

    feature qos {

        description

    }

    feature qos-custom {

        description

    }

    feature rtg-bgp {

        description

    }

    feature rtg-rip {

        description

    }

    feature rtg-ospf {

        description

    }

        description

    }

    feature rtg-vrrp {

        description

    }

    feature fast-reroute {

        description

    }

    feature bfd {

        description

    }

    feature always-on {

        description

        constraint.";

    }

    feature requested-type {

        description

        constraint.";

    }

        description

        constraint.";

    }

[SLI] Ok

[SLI] Thanks for the info.

EDITORIAL:

[SLI] Will take care of these editorial changes.

Regards, Benoit (OPS AD)

_________________________________________________________________________________________________________________________

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: Benoit Claise <[email-masked]>
Date: Fri, 23 Sep 2016 19:02:55 +0200

Thanks for the answers.

Regards, B.
> *From:*L3sm [mailto:[email-masked]] *On Behalf Of *Benoit Claise
> *Sent:* Thursday, September 22, 2016 21:28
> *To:* [email-masked]
> *Subject:* [L3sm] AD review of draft-ietf-l3sm-l3vpn-service-model
>
> Dear authors,
>
> I was wondering why BFD is mentioned in a service model, but it could 
> be fine I guess in case of unmanaged CE. Anyway it's optional.
> [SLI] When discussed, BFD was the most (only ?) used protocol today, 
> that’s why we added it, but nothing prevents augmenting with others.
>
> A few words of reference to LIME in section 5.2.2.2.2 would be 
> welcome, in case we need to augment the OAM container.
> [SLI] Ok
>
>
> 2. QoS Classification
> parameters, and I wonder if it makes sense to have so many details in 
> a service model. Are you really sure that you don't have too much in 
> that area? Don't you need just need a very generic mechanism such as 
> the tc-latency, tc-jitter, tc-bandwidth, tc-path-diversity, and 
> [SLI] This point was discussed when we wrote the QoS parts. Some 
> customers are using flexible QoS models where we gave the ability for 
> them to define their own profile (not completely but a lot of tunable 
> parameters). So the scheduling model supports both well known profiles 
> (gold, silver, bronze …) as well as flexible model.
>
> For classification, there is no choice, customer need to provide 
> inputs for its classification, so must define its flows … it can 
> define it in a abstracted manner (by applications) or again using a 
> flexible policy model when the application is not an existing one.
>
>
> 3. YANG 1.0 or 1.1?
> The write up, 
> [SLI] I was wondering if I could start using some YANG 1.1 features, 
> for example using “feature” for identities.
>
> [email-masked]:1 
> <mailto:[email-masked]:1>: warning: unexpected latest 
> revision "2016-09-13" in [email-masked] 
> <mailto:[email-masked]>, should be 2016-09-15
> sites."

---

From: <[email-masked]>
Date: Tue, 27 Sep 2016 07:50:52 +0000

Hi Qin,

One comment

8.Section 5.1.3
"
The
   proposed model supports ASM, SSM and BiDirectional trees (and can be
   augmented).
"
is there any reference to Bidirectional tree?
[SLI] What reference are you talking about ?

I took care of all other comments for the next revision.
Will publish it soon.

Brgds,

From: Qin Wu [mailto:[email-masked]]
Sent: Friday, September 23, 2016 04:11
To: Benoit Claise; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [L3sm] AD review of draft-ietf-l3sm-l3vpn-service-model

Hi, authors:

4.Section 12.1

5.ID-Nits Checking

"
NEW TEXT:
"

"

Nits/editorial comments:

8.Section 5.1.3
"
The

"

"
s/actives/activates
21.   Section 5.11.1
OLD TEXT
"

"
NEW TEXT:
"

"

24.   Section 5.5.3
s/ fullfilled/fulfilled
收件人: [email-masked]<mailto:[email-masked]>

Dear authors,

Here is my AD review.

1. CE-PE OAM

                  |  +--rw oam

                  |     +--rw bfd {bfd}?

                  |        +--rw (holdtime)?

                  |           +--:(profile)

                  |           +--:(fixed)

2. QoS Classification

3. YANG 1.0 or 1.1?

4.

    feature cloud-access {

        description

         provider.";

    }

    feature multicast {

        description

    }

    feature ipv4 {

        description

    }

    feature ipv6 {

        description

    }

        description

    }

        description

    }

        description

        for multicast.";

    }

    feature extranet-vpn {

        description

    }

    feature site-diversity {

        description

    }

    feature encryption {

        description

    }

    feature qos {

        description

    }

    feature qos-custom {

        description

    }

    feature rtg-bgp {

        description

    }

    feature rtg-rip {

        description

    }

    feature rtg-ospf {

        description

    }

        description

    }

    feature rtg-vrrp {

        description

    }

    feature fast-reroute {

        description

    }

    feature bfd {

        description

    }

    feature always-on {

        description

        constraint.";

    }

    feature requested-type {

        description

        constraint.";

    }

        description

        constraint.";

    }

EDITORIAL:

Regards, Benoit (OPS AD)

---

From: Qin Wu <[email-masked]>
Date: Tue, 27 Sep 2016 09:00:18 +0000

Stephan, thanks for your update. I am not really familiar with Bidirectional tree, but it seems RFC5105 is most relevant(you can search the keyword bidirectional tree), maybe RFC7438 is another one.

-Qin
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2016年9月27日 15:51
收件人: Qin Wu; Benoit Claise; [email-masked]
抄送: [email-masked]; [email-masked]
主题: RE: [L3sm] AD review of draft-ietf-l3sm-l3vpn-service-model

Hi Qin,

One comment

8.Section 5.1.3
"
The

Brgds,

From: Qin Wu [mailto:[email-masked]]
Sent: Friday, September 23, 2016 04:11
To: Benoit Claise; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [L3sm] AD review of draft-ietf-l3sm-l3vpn-service-model

Hi, authors:

4.Section 12.1

5.ID-Nits Checking

"
NEW TEXT:
"

"

Nits/editorial comments:

8.Section 5.1.3
"
The

"

"
s/actives/activates
21.   Section 5.11.1
OLD TEXT
"

"
NEW TEXT:
"

"

24.   Section 5.5.3
s/ fullfilled/fulfilled

Dear authors,

Here is my AD review.

1. CE-PE OAM

                  |  +--rw oam

                  |     +--rw bfd {bfd}?

                  |        +--rw (holdtime)?

                  |           +--:(profile)

                  |           +--:(fixed)

2. QoS Classification

3. YANG 1.0 or 1.1?

4.

    feature cloud-access {

        description

         provider.";

    }

    feature multicast {

        description

    }

    feature ipv4 {

        description

    }

    feature ipv6 {

        description

    }

        description

    }

        description

    }

        description

        for multicast.";

    }

    feature extranet-vpn {

        description

    }

    feature site-diversity {

        description

    }

    feature encryption {

        description

    }

    feature qos {

        description

    }

    feature qos-custom {

        description

    }

    feature rtg-bgp {

        description

    }

    feature rtg-rip {

        description

    }

    feature rtg-ospf {

        description

    }

        description

    }

    feature rtg-vrrp {

        description

    }

    feature fast-reroute {

        description

    }

    feature bfd {

        description

    }

    feature always-on {

        description

        constraint.";

    }

    feature requested-type {

        description

        constraint.";

    }

        description

        constraint.";

    }

EDITORIAL:

Regards, Benoit (OPS AD)

Thank you.

---

From: <[email-masked]>
Date: Tue, 27 Sep 2016 09:21:28 +0000

RFC5015 is the good pointer for PIM Bidir. Do you find necessary to add a reference ?

From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, September 27, 2016 11:00
To: LITKOWSKI Stephane OBS/OINIS; Benoit Claise; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [L3sm] AD review of draft-ietf-l3sm-l3vpn-service-model

-Qin
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
发送时间: 2016年9月27日 15:51
收件人: Qin Wu; Benoit Claise; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: RE: [L3sm] AD review of draft-ietf-l3sm-l3vpn-service-model

Hi Qin,

One comment

8.Section 5.1.3
"
The

Brgds,

Hi, authors:

4.Section 12.1

5.ID-Nits Checking

"
NEW TEXT:
"

"

Nits/editorial comments:

8.Section 5.1.3
"
The

"

"
s/actives/activates
21.   Section 5.11.1
OLD TEXT
"

"
NEW TEXT:
"

"

24.   Section 5.5.3
s/ fullfilled/fulfilled

Dear authors,

Here is my AD review.

1. CE-PE OAM

                  |  +--rw oam

                  |     +--rw bfd {bfd}?

                  |        +--rw (holdtime)?

                  |           +--:(profile)

                  |           +--:(fixed)

2. QoS Classification

3. YANG 1.0 or 1.1?

4.

    feature cloud-access {

        description

         provider.";

    }

    feature multicast {

        description

    }

    feature ipv4 {

        description

    }

    feature ipv6 {

        description

    }

        description

    }

        description

    }

        description

        for multicast.";

    }

    feature extranet-vpn {

        description

    }

    feature site-diversity {

        description

    }

    feature encryption {

        description

    }

    feature qos {

        description

    }

    feature qos-custom {

        description

    }

    feature rtg-bgp {

        description

    }

    feature rtg-rip {

        description

    }

    feature rtg-ospf {

        description

    }

        description

    }

    feature rtg-vrrp {

        description

    }

    feature fast-reroute {

        description

    }

    feature bfd {

        description

    }

    feature always-on {

        description

        constraint.";

    }

    feature requested-type {

        description

        constraint.";

    }

        description

        constraint.";

    }

EDITORIAL:

Regards, Benoit (OPS AD)

Thank you.

---

From: Qin Wu <[email-masked]>
Date: Tue, 27 Sep 2016 09:38:12 +0000

if you think this reference has limitation and restrict Bidir to PIM, you don’t have to. My intention is to make reader better understand the relation between ASM,SSM and Bidir.
Sine this is a minor issue, I like to leave this up to you. Thanks!

-Qin
发送时间: 2016年9月27日 17:21

To: LITKOWSKI Stephane OBS/OINIS; Benoit Claise; [email-masked]<mailto:[email-masked]>

-Qin

Hi Qin,

One comment

8.Section 5.1.3
"
The

Brgds,

Hi, authors:

4.Section 12.1

5.ID-Nits Checking

"
NEW TEXT:
"

"

Nits/editorial comments:

8.Section 5.1.3
"
The

"

"
s/actives/activates
21.   Section 5.11.1
OLD TEXT
"

"
NEW TEXT:
"

"

24.   Section 5.5.3
s/ fullfilled/fulfilled

Dear authors,

Here is my AD review.

1. CE-PE OAM

                  |  +--rw oam

                  |     +--rw bfd {bfd}?

                  |        +--rw (holdtime)?

                  |           +--:(profile)

                  |           +--:(fixed)

2. QoS Classification

3. YANG 1.0 or 1.1?

4.

    feature cloud-access {

        description

         provider.";

    }

    feature multicast {

        description

    }

    feature ipv4 {

        description

    }

    feature ipv6 {

        description

    }

        description

    }

        description

    }

        description

        for multicast.";

    }

    feature extranet-vpn {

        description

    }

    feature site-diversity {

        description

    }

    feature encryption {

        description

    }

    feature qos {

        description

    }

    feature qos-custom {

        description

    }

    feature rtg-bgp {

        description

    }

    feature rtg-rip {

        description

    }

    feature rtg-ospf {

        description

    }

        description

    }

    feature rtg-vrrp {

        description

    }

    feature fast-reroute {

        description

    }

    feature bfd {

        description

    }

    feature always-on {

        description

        constraint.";

    }

    feature requested-type {

        description

        constraint.";

    }

        description

        constraint.";

    }

EDITORIAL:

Regards, Benoit (OPS AD)

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 27 Sep 2016 11:34:21 +0000

I just published a new revision of the draft including all fixes except this one … let’s wait if there is additional comment during IETF last call. I will then add a reference.

Sent: Tuesday, September 27, 2016 11:38

-Qin

-Qin

Hi Qin,

One comment

8.Section 5.1.3
"
The

Brgds,

Hi, authors:

4.Section 12.1

5.ID-Nits Checking

"
NEW TEXT:
"

"

Nits/editorial comments:

8.Section 5.1.3
"
The

"

"
s/actives/activates
21.   Section 5.11.1
OLD TEXT
"

"
NEW TEXT:
"

"

24.   Section 5.5.3
s/ fullfilled/fulfilled

Dear authors,

Here is my AD review.

1. CE-PE OAM

                  |  +--rw oam

                  |     +--rw bfd {bfd}?

                  |        +--rw (holdtime)?

                  |           +--:(profile)

                  |           +--:(fixed)

2. QoS Classification

3. YANG 1.0 or 1.1?

4.

    feature cloud-access {

        description

         provider.";

    }

    feature multicast {

        description

    }

    feature ipv4 {

        description

    }

    feature ipv6 {

        description

    }

        description

    }

        description

    }

        description

        for multicast.";

    }

    feature extranet-vpn {

        description

    }

    feature site-diversity {

        description

    }

    feature encryption {

        description

    }

    feature qos {

        description

    }

    feature qos-custom {

        description

    }

    feature rtg-bgp {

        description

    }

    feature rtg-rip {

        description

    }

    feature rtg-ospf {

        description

    }

        description

    }

    feature rtg-vrrp {

        description

    }

    feature fast-reroute {

        description

    }

    feature bfd {

        description

    }

    feature always-on {

        description

        constraint.";

    }

    feature requested-type {

        description

        constraint.";

    }

        description

        constraint.";

    }

EDITORIAL:

Regards, Benoit (OPS AD)

Thank you.

Thank you.

---

From: Qin Wu <[email-masked]>
Date: Wed, 28 Sep 2016 01:53:46 +0000

Wonderful, thank for taking this into consideration.

-Qin
发送时间: 2016年9月27日 19:34

-Qin

-Qin

Hi Qin,

One comment

8.Section 5.1.3
"
The

Brgds,

Hi, authors:

4.Section 12.1

5.ID-Nits Checking

"
NEW TEXT:
"

"

Nits/editorial comments:

8.Section 5.1.3
"
The

"

"
s/actives/activates
21.   Section 5.11.1
OLD TEXT
"

"
NEW TEXT:
"

"

24.   Section 5.5.3
s/ fullfilled/fulfilled

Dear authors,

Here is my AD review.

1. CE-PE OAM

                  |  +--rw oam

                  |     +--rw bfd {bfd}?

                  |        +--rw (holdtime)?

                  |           +--:(profile)

                  |           +--:(fixed)

2. QoS Classification

3. YANG 1.0 or 1.1?

4.

    feature cloud-access {

        description

         provider.";

    }

    feature multicast {

        description

    }

    feature ipv4 {

        description

    }

    feature ipv6 {

        description

    }

        description

    }

        description

    }

        description

        for multicast.";

    }

    feature extranet-vpn {

        description

    }

    feature site-diversity {

        description

    }

    feature encryption {

        description

    }

    feature qos {

        description

    }

    feature qos-custom {

        description

    }

    feature rtg-bgp {

        description

    }

    feature rtg-rip {

        description

    }

    feature rtg-ospf {

        description

    }

        description

    }

    feature rtg-vrrp {

        description

    }

    feature fast-reroute {

        description

    }

    feature bfd {

        description

    }

    feature always-on {

        description

        constraint.";

    }

    feature requested-type {

        description

        constraint.";

    }

        description

        constraint.";

    }

EDITORIAL:

Regards, Benoit (OPS AD)

Thank you.

Thank you.

Thank you.