Subject: [Lime] Review of draft-kumar-lime-yang-connectionless-oam-02

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 30 May 2016 23:35:39 -0700

[Correcting the address]

This is my review of draft-kumar-lime-yang-connectionless-oam-02. I know the authors have posted an updated version, but this review does not cover those changes.

YANG doctors, please note that the even though we review WG documents before I-D, I am reviewing this as it has impact on other YANG modules that are WG documents.

The introduction says 

  "In this document, we presents a base YANG Data model for
   connectionless OAM protocols which supports generic continuity or
   reachability check, and path discovery.”

s/presents/present/

First of all, I am not sure how the YANG module does an “or” of some technologies and ‘and' of different technologies. As I see it, it offers a solution for all of them, so an ‘and’ of all would probably be the right description. Secondly, it would help to know somewhere in the document what technology would use generic continuity, which one would use reachability check and which one would use path discovery.

Secondly, it is not clear what would be the use case for this YANG module. Maybe the authors can start by defining how they see the YANG module being used by an orchestrator or a controller.

Finally, and most importantly, the YANG module seems to offer two things. A set of test point locations (which in itself is not clear from a definition perspective, see below) and a definition of different layers of OAM technology. By the time, the YANG module has captured all the addresses, technology, and tool sets, the list is so long that most modules that will want to use this YANG module will find that most of the module is not relevant to them. A general rule of augmentation is that what is being augmented is mostly relevant to the module that is augmenting it, and only certain parts need augmentation. That does not seem to be the case here. While I commend the authors in trying to find things that are common from a configuration perspective, the disparate nature of OAM technologies out there lends very little that is indeed common. Which goes back to the question of what is the use case for this module?

A better use of the module would be for it to make references into the disparate OAM technologies to collect operational data and give a layer independent view of any fault situation in the network to the customer.

The tracking and stitching of different layers of OAM technology can also be helpful for tracking of faults. But other than specifying the different layers and making a ordered-by-user list, the YANG model does not seem to offer a solution or point to one that justifies the current structure of the model. It assumes the controller has a better idea of what the different layers are in the box, which I am not sure is the case. Being able to offer a solution in this space, even if it from a operational perspective is one of the best things this module can offer. Unfortunately, it is not there in this version.

More detail comments follow:

Section 3:

The document makes reference to something called “Model”. If it is the YANG model that the authors are referring to within the document, then s/Model/YANG module/g.

The YANG module makes reference to a ‘vrf’ from routing module, which since version 21 does not exist anymore. So LIME will have to update its reference or remove it in its YANG module.

The document also makes a reference to test-point-location-list, but as far as I can see, I do not see any reference to what that is in the YANG module or the rest of the document. As far as I can see, there is a list ‘test-point-locations’ which has one or more ‘test-point-location’.

The document makes extensive use of ietf-network.yang module, but cites no reference to it before it uses it. A reference to the draft that contains the module would be helpful.

The document also makes extensive references to ‘technology’ but it is not clear what the meaning of that is in the document. Is it OAM technology? In the YANG model, there is reference to ‘technology-null’ when no ‘technology’ needs to be defined, and there is ‘technology-string’ which is of type string, which seems to indicate it can be any arbitrary string. However, the description says it is a “name to identify oam technology”. Seems this should be an identity-ref rather than of type string.

Section 3.1

What is “tp”? If it is Test Point, then use the acronym defined above which is TP. I did a Wikipedia search for TP, but saw no reference to TP. A search of Test Point revealed more of a reference to "location within an electronic circuit that is used to either monitor the state of the circuitry or to inject test signals.” A more relevant reference or a new definition would be helpful.

Section 3.3

What is level 0? Who defines what is level 0? Who defines what is a client layer and what is a server layer? What happens if the fault happens more than one layer away? BFD fault on a LAG that has a LSP with a PW running on top? How will that be represented? How does notification of faults happen?

Section 3.6

test-point-ipv4-location-list contains both an ipv4 and a ipv6 address. Same for test-point-ipv6-location-list.

The indentations in the module are incorrect, and make it very hard to read the model, like the one below. The description statement are non-descriptive and say very little about the attribute than what is apparent from the name. It would really help to make the statements more descriptive.

     container test-point-ipv4-location-list {
        if-feature connection-less;
        list test-point-locations {
        key "ipv4-location";
        leaf ipv4-location {
            type inet:ipv4-address;
            description
              "Ipv4 Address.";
        }
        uses test-point-location;
        ordered-by user;
        description
           "list of test point locations.";
      }
          description
          "Serves as top-level container for test point location list.";
    }

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: wangzitao <[email-masked]>
Date: Tue, 31 May 2016 08:30:29 +0000

Hi Mahesh,
Thank you for reviewing this draft, and  these valuable comments
please find my answer in-line and tagger [ZITAO]

Best Regards!
-Michael

发件人: Lime [mailto:[email-masked]] 代表 Mahesh Jethanandani
发送时间: 2016年5月31日 14:36
收件人: [email-masked]
抄送: [email-masked]
主题: [Lime] Review of draft-kumar-lime-yang-connectionless-oam-02

[Correcting the address]

The introduction says

s/presents/present/

First of all, I am not sure how the YANG module does an “or” of some technologies and ‘and' of different technologies. As I see it, it offers a solution for all of them, so an ‘and’ of all would probably be the right description. Secondly, it would help to know somewhere in the document what technology would use generic continuity, which one would use reachability check and which one would use path discovery.
[ZITAO]: In this module we defined the test point configuration model, and some RPC format (continuity check, path discovery).
Here the “continuity or reachability check” means continuity check.

Secondly, it is not clear what would be the use case for this YANG module. Maybe the authors can start by defining how they see the YANG module being used by an orchestrator or a controller.
[ZITAO]: Thank you, we will consider it.

Finally, and most importantly, the YANG module seems to offer two things. A set of test point locations (which in itself is not clear from a definition perspective, see below) and a definition of different layers of OAM technology.
[ZITAO]: Here we define the a set of test points and build the relationship of them.
For example, in a test point list we defined the tp-address, supporting tools and oam-layer.
OAM-layers is referred to a list of OAM layers above and below that are related to current test point.
It allow users to navigate up and down to quickly localize fault.

By the time, the YANG module has captured all the addresses, technology, and tool sets,
[ZITAO]: The test point address we defined here are choice/case nodes,
the user can choose a proper case basis of their own needs

the list is so long that most modules that will want to use this YANG module will find that most of the module is not relevant to them.
[ZITAO]: Thank you for pointing that, we will consider to optimize it.

A general rule of augmentation is that what is being augmented is mostly relevant to the module that is augmenting it, and only certain parts need augmentation.
[ZITAO]: I agree.

That does not seem to be the case here. While I commend the authors in trying to find things that are common from a configuration perspective, the disparate nature of OAM technologies out there lends very little that is indeed common.
[ZITAO]: Thank you, we will consider to optimize it.

Which goes back to the question of what is the use case for this module?

[ZITAO]: Indeed.

The tracking and stitching of different layers of OAM technology can also be helpful for tracking of faults.
[ZITAO]: Yes, It is exactly what we want to do!
But other than specifying the different layers and making a ordered-by-user list, the YANG model does not seem to offer a solution or point to one that justifies the current structure of the model. It assumes the controller has a better idea of what the different layers are in the box, which I am not sure is the case. Being able to offer a solution in this space, even if it from a operational perspective is one of the best things this module can offer. Unfortunately, it is not there in this version.
[ZITAO]: the oam layer we define here, is want to built a relationship of different test points.

It is not the traditional ip layer, Ethernet layer, etc.

It defined a list of related oam layers: 0 means they are in same level, especially interworking scenarios of stiching multiple technology at same layer.
-1 means server layer, for eg:- in case of Overlay and Underlay, Underlay is server layer for Overlay Test Point.
+1 means client layer, for eg:- in case of Service OAM and Transport OAM, Service OAM is client layer to Transport OAM.

Section 3:

The document makes reference to something called “Model”. If it is the YANG model that the authors are referring to within the document, then s/Model/YANG module/g.
[ZITAO]: Thank you! We will fix it.

The YANG module makes reference to a ‘vrf’ from routing module, which since version 21 does not exist anymore. So LIME will have to update its reference or remove it in its YANG module.
[ZITAO]: Yes, we have already fixed it in 03 version☺

The document also makes a reference to test-point-location-list, but as far as I can see, I do not see any reference to what that is in the YANG module or the rest of the document. As far as I can see, there is a list ‘test-point-locations’ which has one or more ‘test-point-location’.
[ZITAO]: Thank you for pointing that.

The document makes extensive use of ietf-network.yang module, but cites no reference to it before it uses it. A reference to the draft that contains the module would be helpful.
[ZITAO]: Thank you! We will fix it in next version.

The document also makes extensive references to ‘technology’ but it is not clear what the meaning of that is in the document. Is it OAM technology? In the YANG model, there is reference to ‘technology-null’ when no ‘technology’ needs to be defined, and there is ‘technology-string’ which is of type string, which seems to indicate it can be any arbitrary string. However, the description says it is a “name to identify oam technology”. Seems this should be an identity-ref rather than of type string.
[ZITAO]: good point. We will consider to update it in next version.

Section 3.1

What is “tp”? If it is Test Point, then use the acronym defined above which is TP. I did a Wikipedia search for TP, but saw no reference to TP. A search of Test Point revealed more of a reference to "location within an electronic circuit that is used to either monitor the state of the circuitry or to inject test signals.” A more relevant reference or a new definition would be helpful.
[ZITAO]: It means test point. And in last lime interim meeting, Greg also give us similar advice(Thank you Greg!). We would to add it in next version.

Section 3.3

What is level 0? Who defines what is level 0? Who defines what is a client layer and what is a server layer? What happens if the fault happens more than one layer away? BFD fault on a LAG that has a LSP with a PW running on top? How will that be represented? How does notification of faults happen?
0 means they are in same level, especially interworking scenarios of stiching multiple technology at same layer.
-1 means server layer, for eg:- in case of Overlay and Underlay, Underlay is server layer for Overlay Test Point.
+1 means client layer, for eg:- in case of Service OAM and Transport OAM, Service OAM is client layer to Transport OAM.

Section 3.6

test-point-ipv4-location-list contains both an ipv4 and a ipv6 address. Same for test-point-ipv6-location-list.
[ZITAO]: The test point address are choice/case nodes, the user can choose a proper case according to their own needs.
And we will consider to optimize these attributes.

        key "ipv4-location";

        leaf ipv4-location {

            type inet:ipv4-address;

            description

              "Ipv4 Address.";

        }

        ordered-by user;

        description

      }

          description

    }

Thanks.

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