Subject: Re: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03

From: wangzitao <[email-masked]>
Date: Fri, 3 Feb 2017 06:10:53 +0000

Thank Adrian for these valuable comments, please find my reply inline.

Best Regards!
-Michael

-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Adrian Farrel
发送时间: 2017年1月25日 20:40
收件人: 'Ron Bonica'; [email-masked]; [email-masked]
主题: Re: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03

Hi, 

I read this document as part of the WG last call. 

In my opinion the document is *almost* ready to move forward, but has some small issues that need to be resolved first.

Thanks for the work,
Adrian

===

The use of English could use some work. The RFC Editor will catch this, but there is a risk that they will break something, so if you have the chance to get someone to edit the document first, that would help.

---

There are a number of nits reported at
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf
-lime-yang-connectionless-oam-03.txt
[Michael]: Thanks, and we would like to fix them.
---

The datatracker is reporting "Submission Yang Validation returned warnings or errors." No idea about this, but sounds like something that should be fixed.
[Michael]: Thanks, and we would like to fix them.
---

Need to expand "OAM" in the Abstract.
[Michael]: Agree.
---

Abstract s/Based model/Base model/
[Michael]: Thanks, we will fix it.
---

I think the Introduction would benefit from a short paragraph referencing draft-ietf-lime-yang-oam-model and explaining the difference.
[Michael]: It make sense to me, I would like to discuss with my coauthor to add some explaining in next version.
---

Section 1 has tree citations of "[lime retrieval methods]". You need to sort this out.
[Michael]: Yes, we will fix it in next version.
(I suspect idnits catches this)

---

Section 2.2. See my comments on the equivalent section in draft-ietf-lime-yang-oam-model
[Michael]: Agree.
---

Section 3, etc.
Probably best to use single quotes (') around names of data nodes etc.
Thus, for example, 
   At the top of the Model, there is an 'oper' container for session
[Michael]: Agree.
---

In 3.3 I can't make sense of
   Level is provided for scenarios where
   it might be possible to define layering relationship as it can be
   used to stitching fault at related OAM layers.

It seems to me (from the example that follows) that you are not talking about layering of network technologies so much as concatenation of path segments each of which is at a different technology. Maybe rewrite the text as...
   'Level' defines the relative technology level in a sequence of 
   network portions, and is provided to allow correlation of faults in
   related OAM domains.
Or maybe I am only guessing.
[Michael]: I would to discuss with other authors to make it more clearly.
---

3.3
s/thesecond/the second/
[Michael]: Agree.
---

3.3

                  leaf level {
                      type int32 {
                           range "-1..1";
                      }
                      description
                        "Level";
                  }

It's not important, but I did wonder whether you would be better defining "up", "same", and "down" rather than using an int32.
[Michael]: I would to discuss with other authors to decide whether change it.
---

A number of description clauses need to begin with capital letters.
[Michael]: Agree, I will fix it in next version.
---

I am trying to understand how a test point location can be identified by a multicast group address. I think you might want to target some of the OAM tools at a multicast address (e.g., ping a mcast address) but I don't see this as the same as a text point location. Am I missing something?
[Michael]: I will discuss with other authors, and improve it.
---

You define oam-counter32 but then a number of leaf nodes (such as
session-count) are of type uint32. In fact, I don't see oam-counter32 used at all.
[Michael]: Yes, it need to be removed.
---

    grouping session-packet-statistics {
      description "Grouping for per session packet statistics";
      container session-packet-statistics {

        description "Per session packet statistics.";
        leaf rx-packet-count {
          type uint32;
          description "Total received packet count.";
        }
        leaf tx-packet-count {
          type uint32;
          description "Total transmitted packet count.";
        }
        leaf rx-bad-packet {

          type uint32;
          description "Total received bad packet.";
        }
        leaf tx-packet-failed {
          type uint32;
          description "Total send packet failed.";
        }
      }
    }

Please clarify whether this is "Total number of OAM packets..." If it is counting normal data packets, uint32 is not large enough.
[Michael]: Agree, and I will fix it in next verison.
---

    grouping session-path-verification-statistics {
      description "Grouping for per session path verification statistics";
      container session-path-verification-statistics{
        description "OAM per session path verification statistics.";
        leaf verified-count {
          type uint32;
          description "Total number of packets that went through a path as intended.";
        }
        leaf failed-count {
          type uint32;
          description "Total number of packets that went through an unintended path.";
        }
      }
    }

Please clarify whether this is "Total number of OAM packets..." If it is counting normal data packets, uint32 is not large enough.
[Michael]: Agree, and I will fix it in next verison.
---

Not sure why you need to define IP-Multicast-Group-Address since a mcast IP address surely looks a lot like an IP address for which types already exist.
[Michael]: I would to discuss with other authors to decide whether remove it.
---

Quite a few places "IP" is presented as "Ip"
[Michael]: Agree, I will fix it in next version.
---

      container path-verification {
        description "Optional path verification related information.";
        leaf flow-info {
          type string;
          description
            "ACL name that refers to the flow, if any.";
        }
        uses session-path-verification-statistics;
      }

Why "ACL name"? Why does this have anything to do with ACLs?
[Michael]: I would to discuss with other authors to make it more clearly.
 (But if it does, you need to expand ACL.)

---

Superfluous "YANG module of OAM" right at the end of the YANG module
[Michael]: Indeed, it need to be fixed.
---

5.  CL model applicability

Spell out "CL" or use actual model name.
[Michael]: Agree
---

6.  Security Considerations

   TBD.

I don't think that will be good enough :-) You can model on the text in draft-ietf-lime-yang-oam-model
[Michael]: Indeed, I will fix it in next version.
---

Section 8

   The authors of this document would like to thank Greg Mirskey and
   others

Greg spells it "Mirsky".
The others wished to remain anonymous?
[Michael]: Thanks for point it, we will fix it.
---

It is possible that all your references are normative, but I doubt it.
You should go through them and work out which provide information and which are required reading in order to process this document.
[Michael]: Agree, we would like to optimize the reference section.
> -----Original Message-----
> From: Lime [mailto:[email-masked]] On Behalf Of Ron Bonica
> Sent: 19 January 2017 16:12
> To: [email-masked]; 
> [email-masked]
> Subject: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03
> 
> Folks,
> 
> This message begins a Working Group Last Call on draft-ietf-lime-yang- 
> connectionless-oam-03. Please submit comments by February 3, 2017.
> 
>
Ron
> 
> _______________________________________________
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime

_______________________________________________
Lime mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lime

---

From: "Srihari Raghavan (srihari)" <[email-masked]>
Date: Tue, 7 Feb 2017 09:15:00 +0000

Hi Greg

Thanks much for your comments and for your time.  Pl. find replies inline.

Thanks
Srihari

From: Lime <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 31 January 2017 at 11:36 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03

Dear Authors, LIME WG Chairs, et.al<http://et.al>,
please consider my comments as part of WG LC discussion.

  *

3.1<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.1>.  TP Address

     *   I think that this topic requires more discussion. In what case, which network technology developed at IETF MAC may identify test point? [Authors]: Please refer to VPLS technology described in RFC6136.
     *   FEC is the most common case among listed. In fact, FEC unlikely fits into this list if we understand it as group of IP packets which are forwarded in the same manner over the same path, and with the same forwarding treatment. In other words, we have the same destination, same next hop, egress interface and CoS marking (note that some of these parameters may be as wild card).  [Authors]: Note that FEC is special type of tp-address-type-value. The FEC defined here is used as test point addressing, not focus on forwarding treatment, maybe we could change the terminology into something else to avoid confusion.  Pl. see next bullet.
     *   IP Address, whether v4 or v6, does not sufficiently define the Test Point and must be associated with the parameter that defines forwarding treatment of a test packet addressed to the Test Point, e.g. DSCP for IP or TC for MPLS. True, often CoS parameter is set by default but that doesn't exclude it from the list of parameters that define the Test Point. [Authors]: The test point defined here is an abstract conception. It is a technology independent attribute. Therefore, we only defined test-point-location/address to distinguished different test point type.  Model user can extend the test point by adding other technology specific parameters. Not sure forwarding treatment should be part of test point location in this base model.  Perhaps, a generic name like ‘addressing-attribute’ or ‘addressing-type’ or ‘TP-attribute’ that can take on values like DSCP for IP or TC for MPLS and can replace the ‘FEC’ in the previous bullet.
     *   I don't know of a case when this is true "a pair of source, destination addresses, and interface (Useful for BFD)". Could you please elaborate, give an example?[Authors]: According to previous discussion, these need be removed. It will be fixed in next version.
     *   "System-id to represent the device or node" Like in Segment Routing? Example, reference would be helpful.  [Authors] System-id as written in the document refers to something that identifies the system in the network and hence could be ‘router-id’ similar to ISIS usage.  Pl. refer: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-05. We will add some explanations in next version.
  *

3.2<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.2>.  Tools

     *   "performance measurement" As I understand, model of performance measurement OAM is outside the scope of this document. [Authors]: Thanks, we will fix it.
     *   I think this section would be the proper place do discuss proactive and on-demand OAM tools, give examples of each and how they being used in network operations. [Authors]: Yes, we propose to do that in next version.
  *

3.3<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.3>.  OAM-layers

     *   "each layer has its own OAM protocols"
        *   s/protocols/protocol/
        *   I think that that is not necessarily the case, e.g. BFD may be used in IP/MPLS underlay and L3VPN overlay.[Authors]: Agree. Perhaps it can modified to “each layer may have its own OAM protocol”.
     *   "OAM-layers is referred to a list of upper layer, lower layer that are related to current test point. This allow users to easily navigate up and down to efficiently troubleshoot a connectivity issue at different layer."
        *   Something is missing in the first sentence.
        *   s/this allow/this allows/[Authors]: Will fix.
        *   Connectionless network does not include connection as element of its architecture and thus there's no mis-connection defect. Perhaps you were referring to loss of continuity defect here.[Authors]: The intention is to track down fault at the adjacent layer that is beyond connectionless nework. If this creates confusion, we can remove connection-oriented-location parameter.
     *   I don't agree with the proposed use of OAM level. If we consider OAM of a service that traverses multiple administrative domains, then Service OAM must be at the same level regardless of domain. Service OAM would be the outmost top level. Each operator may enable OAM test points in its respective segment so that each of segment would be at the same OAM level, e.g. Link OAM at the very bottom with Segment OAM between Service and Link OAM levels. [Authors]: The oam level can help to improve efficiency of fault localization. For example, the user may track down fault location by correlating faults at different levels and different locations and after checking the OAM levels, initiate ‘triggered’ or ‘follow-on’ OAM detection.  But as you mention, by default, a test point will be set in the same level.
  *

3.5<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.5>.  Test Point Locations

     *   The last sentence is hard to parse and it leaves impression of circular reference with the definition of Test Point Location Information definition in the previous section.
  *   "... data model is made generic enough to allow active, passive and hybrid OAMs to do the retrieval"
     *   This being mentioned in reference to Path Discovery Data and Continuity Check Data. I'd imagine that an OAM mechanism, would it be active, passive or hybrid, produces the data but the retrieval of data done using non-OAM protocol, e.g. RPC, gRPC or else. [Authors]: Thanks, we will fix it by re-wording it to say, retrieval by multiple methods.
  *

3.8<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.8>.  OAM data hierarchy

     *   I think that "oper" as name for the container that holds operational information is confusing. Could it be extended, more self-explanatory?  [Authors]: Thanks, we would like to make it more clearly. May be we can call it ‘cc-oper-data’…Thoughts?
     *   I there are more than two types of TP (IPv4 or IPv6), e.g. System-id, why container oper for continuity-check statistics holds only for IPv4 and IPv6 types of TP? [Authors]:Here we want to define the most common case of operation statistics, therefore, it holds only for IPv4 & IPv6. And extensions are possible by future designers.
     *   as-number-location may be part of tp-address, but as identifier of a Test Point? Could you please give an example.  [Authors]:They may be used by VPNv4/VPNv6 opaque encoding
     *   I believe that connection-oriented-location as part of tp-address grouping is not correct.  [Authors]: we will remove this parameter in the next version.
     *   As connectionless network does not use notion of connection, OAM in connectioless network does not include tools to conduct connectivity verification and to detect mis-connection defect. Hence there's no definition of in and out of mis-connection defect for connectionless networks.  [Authors]: Our understanding: Please refer to table 4 of RFC7276 In RFC7276,CV has broad meaning and which can be applied to both CO network and CL network.
     *   I don't agree with the list of values the 'tp-address-type-value' leaf may take. As noted earlier, MAC unlikely to be used as address of a test point in connectionless network and so FEC identifier.  [Authors]: Our understanding: As mentioned above under MAC and FEC discussion, different layer OAM has different addressing mechanism, FEC identifier can be regarded as a special location value which is applied to a portion of the network or network segment…maybe we can change 'tp-address-type-value' into 'tp-location-type-value’.  Thoughts?

Nits:

  *   cc - is missing from Terminology section
  *    FEC is missing from Terminology section
  *   [lime retrieval methods] appears as reference but has no real document it points to[Authors] Will fix in the next revision.

I don't support publication of this version.

Regards,
Greg

  *

On Thu, Jan 19, 2017 at 8:12 AM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

This message begins a Working Group Last Call on draft-ietf-lime-yang-connectionless-oam-03. Please submit comments by February 3, 2017.

                                                                            Ron

_______________________________________________
Lime mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lime