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

From: Ron Bonica <[email-masked]>
Date: Thu, 19 Jan 2017 16:12:14 +0000

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 24 Jan 2017 07:24:48 +0000

Support and I have a few suggested changes to v-(03).
1. Add reference for Proactive OAM session, I think RFC7276 provides 
 a good references for the term 'proactive activation'.
2. Add reference for active, passive and hybrid OAM, I think RFC7799
provides a good references for active method, passive method and hybrid method
These methods are related to performance measurement, which is part of OAM. Therefore RFC7799 would be a good 
reference for active passive and hybrid OAM.
3.Add informative reference to I-D.ietf-lime-yang-connectionless-oam-methods.
4. Change [lime retrieval methods] into [I-D.ietf-lime-yang-connectionless-oam-methods].
5. Section 3
OLD TEXT:
"
The level in oam-layers indicate whether related oam test point is
client layer, server layer or same layer.
"
NEW TEXT:
"
The level in oam-layers indicate whether related oam test point is
in client layer(lower layer described in section 3.3), server layer
(upper layer described in section 3.3) or the same layer as the current 
test point under Test point Locations.
"
6. Section 6, complete the empty section as follows:
"
   The YANG module defined in this memo is designed to be accessed via
   the NETCONF protocol [RFC6241] [RFC6241].  The lowest NETCONF layer
   is the secure transport layer and the mandatory-to-implement secure
   transport is SSH [RFC6242] [RFC6242].  The NETCONF access control
   model [RFC6536] [RFC6536] provides the means to restrict access for
   particular NETCONF users to a pre-configured subset of all available
   NETCONF protocol operations and content.

   There are a number of data nodes defined in the YANG module which are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., <edit-config>)
   to these data nodes without proper protection can have a negative
   effect on network operations.

   The vulnerable "config true" subtrees and data nodes are the
   following:

/nd:networks/nd:network/nd:node/coam:location-type/coam:ipv4-location-type/coam:test-point-ipv4-location-list/coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:ipv6-location-type/coam:test-point-ipv6-location-list/coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:mac-location-type/coam:test-point-mac-address-location-list/coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:tunnel-location-type/coam:test-point-tunnel-address-location-list/coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:ip-prefix-location-type/coam:test-point-ip-prefix-location-list/coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:route-distinguisher-location-type/coam:test-point-route-dist-location-list/coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:group-ip-address-location-type/coam:test-point-group-ip-address-location-list/coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:group-as-number-location-type/coam:test-point-as-number-location-list/coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:group-lsp-id-location-type/coam:test-point-lsp-id-location-list/coam:test-point-locations/
/nd:networks/nd:network/nd:node/coam:location-type/coam:group-system-id-location-type/coam:test-point-system-info-location-list/coam:test-point-locations/

   Unauthorized access to any of these lists can adversely affect OAM
   management system handling of end-to-end OAM and coordination of OAM
   within underlying network layers. This may lead to inconsistent
   configuration, reporting, and presentation for the OAM mechanisms
   used to manage the network.
"

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

Folks,

                                                                            Ron

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

---

From: Dapeng Liu <[email-masked]>
Date: Tue, 24 Jan 2017 15:38:16 +0800

Hi,

"I have read the most recent revision,and think it is ready for publication.
One nits I spot is in section 7:
"
name: ietf-connectionless-oam namespace: urn:ietf:params:xml:ns:yang:
ietf-connectionless-oam
   prefix: goam reference: RFC XXXX
"
I think the prefix should be "prefix:coam" instead of "prefix:goam" since
the prfix:goam has been allocated for CO model.

Thanks,
Dapeng Liu

2017-01-20 0:12 GMT+08:00 Ron Bonica <[email-masked]>:

> 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
>

-- 

------
Best Regards,
Dapeng Liu

---

From: Fioccola Giuseppe <[email-masked]>
Date: Wed, 25 Jan 2017 11:01:37 +0000

Hi,
I have read this document and support it.
I also agree about adding reference for passive, active and hybrid performance measurements (e.g. RFC7799).

Thanks,

Giuseppe

-----Messaggio originale-----
Da: Lime [mailto:[email-masked]] Per conto di Ron Bonica
Inviato: giovedì 19 gennaio 2017 17:12
A: [email-masked]; [email-masked]
Oggetto: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03

Folks,

                                                                            Ron

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Jan 2017 12:39:34 -0000

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

---

The datatracker is reporting "Submission Yang Validation returned 
warnings or errors." No idea about this, but sounds like something that
should be fixed.

---

Need to expand "OAM" in the Abstract.

---

Abstract s/Based model/Base model/

---

I think the Introduction would benefit from a short paragraph 
referencing draft-ietf-lime-yang-oam-model and explaining the 
difference.

---

Section 1 has tree citations of "[lime retrieval methods]". You need
to sort this out.

(I suspect idnits catches this)

---

Section 2.2. See my comments on the equivalent section in 
draft-ietf-lime-yang-oam-model

---

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

---

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.

---

3.3
s/thesecond/the second/

---

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.

---

A number of description clauses need to begin with capital letters.

---

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?

---

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.

---

    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.

---

    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.

---

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.

---

Quite a few places "IP" is presented as "Ip"

---

      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?

(But if it does, you need to expand ACL.)

---

Superfluous "YANG module of OAM" right at the end of the YANG module

---

5.  CL model applicability

Spell out "CL" or use actual model name.

---

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

---

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?

---

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.

> -----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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 31 Jan 2017 10:06:40 -0800

Dear Authors, LIME WG Chairs, 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?
      - 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).
      - 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
      - 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?
      - "System-id to represent the device or node" Like in Segment
      Routing? Example, reference would be helpful.
   -

   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.
      - 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.
   -

   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.
      - "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/
         - 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.
      - 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.
   -

   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.
   -

   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?
      - 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?
      - as-number-location may be part of tp-address, but as identifier of
      a Test Point? Could you please give an example.
      - I believe that connection-oriented-location as part of tp-address
      grouping is not correct.
      - 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.
      - 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

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

I don't support publication of this version.

Regards,
Greg

   -