Subject: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

From: Yuji Tochio <[email-masked]>
Date: Wed, 24 Jun 2015 15:54:50 +0900

Hi all,

The authors of draft-tissa-lime-yang-oam-model asked for comments to the authors of draft-lam-lime-summary-l0-l2-layer-independent.
So far, I, as a co-author of draft-lam..., have collected comments among us and here are attached the comments as below.

I hope the comments will contribute the progress of draft-tissa-lime-yang-oam-model.

Regards,
Yuji

------
Comments

1. Common OAM architecture

This document defines the relationship of different OAM YANG model that covers MPLS, IP, NVO3, TRILL and so on. But there seems to be no Common OAM architecture 
for them, but the common OAM architecture in this draft adapts those for Ethernet (IEEE802.1Q and ITU-T G.8013/Y.1731) or MPLS-TP (RFC 6371).
Given that this draft covers only Ethernet and MPLS-TP OAM, it would not have any issues. But how about other technologies like IP or (IP/)MPLS? Do they use the 
architecture same as Ethernet or MPLS-TP?

2. Common tools for OAM

The current draft only describes based on Ethernet CCM so that all the parameters in the draft come basically from those for configuring MEPs of Ethernet (and 
some for IPv4 and IPv6).
For the definition of Generic OAM, it is required to describe what kind of the tool sets are considered in this draft.
The good example is in Table 7-1 of ITU-T G.8113.2.

3. Configuration data structure for MEP (section 4.3)

Reading MEP in ietf-gen-oam, the MEP is regarded as bidirectional end point that includes both generation process and reception process.
ITU-T G.8052 (or ONF work for OAM) defines MEP that includes generation process and reception process (i.e. Source and Sink).
In fact, Ethernet CCM works as one-way (called Dual-ended) so that the clear distinction for MEP source and sink is defined in G.8052.
This draft should be consider MEP source and sink.
Also co-located sink MEP in case of a bi-directional connection should be considered.

4. Output in rpcs
Output in rpcs includes performance monitoring (i.e Delay measurement, Loss measurement)related configuration data, But it looks as a part of CC and CV 
functionalities.
As seen in ITU-T G.8013 (DM, LM, and Synthetic LM) and PM for Trill OAM, the output (PM related configuration data) should be regarded in more generic way.
BTW, the YANG for the output says:

     output {
       uses monitor-stats {
         description
           "Stats of continuity check is same as that of
            monitor sessions";
       }
     }
   }

What does mean by "Stats of continuity check is same as that of monitor sessions"?

5. Defect type

It describes as:
    notifications:
       +---n defect-condition-notification
          +--ro technology          identityref
:
          +--ro defect-type?        identityref

The authors are interested in what kind of types are in for defect-type.
In general, like section 4.4 (rpc), it is expected that the detailed/clarified section for notification is added.

6. Comments on Introduction (Section 1)

Three comments:

(1) Three bullets should be updated as:
1.  monitor networks --> 1. monitor connections
2. isolation --> localization
3. measure performance --> 3. monitor performance (loss, delay).

(2) "The YANG data model presented in this document occurs at the management layer."
should this be:
"The YANG data model presented in this document exists at themanagement layer."

(3) The sentence in the last paragraph "This ability to go up and down to different layers" is not a good description for "nesting".

7. Comment on Terminology (Section 2.1)

Since the model is based on IEEE802.1Q, the expansion for MEP and MIP should follow IEEE802.1Q.

8. Comments on Overview of the OAM Model (Section 4)

Three comments:

(1) What is a "parallel vertical"?
(2) What is "rpc"? (expansion is missing) And note that both rpc and RPC is used throughout the draft.
(3) The sentence "Under each MA, there can be two or more MEPs "implies that the two MEPs are the source and sink of a connection, Does this mean that for a 
bi-directional (transport) connection there are two MAs?

9. Comment on OAM data hierarchy (Section 4.5)

It is suggested to move the first part (from:  The following notations" until "leafs and leaf-lists ") to the front of section 4, because the notation is also 
used in sections 4.1... 4.4.
------

---

From: Huub van Helvoort <[email-masked]>
Date: Sat, 27 Jun 2015 10:24:18 +0200

All,

Some additional remarks on draft-tissa-lime-yang-oam-model-05

In the introduction section:

this because actually the connections in the network are
monitored.

2. isolation --> localisation

it is not always possible to isolate a fault, but if one can
locate it

one can take proper consequent actions (like isolation)

3. measure performance --> 3. monitor performance (loss,
delay).

monitor implies that consequent actions may/will be taken/

Proper expansion of MEP (from 802.1):

3.93 Maintenance
association End Point (MEP)

Proper expansion of MIP (from 802.1Q):

3.98 Maintenance
domain Intermediate Point (MIP)

Best regards, Huub.

BTW: the latter two remarks are also applicable to

draft-tissa-nvo3-oam-fm-02

IEEE Std 802.1Q™-2011, IEEE Standard for Local and
metropolitan area networks—Media Access Control (MAC) Bridges
and Virtual Bridged Local Area Networks

-------

Hi
all,

The authors of draft-tissa-lime-yang-oam-model asked for comments
to the authors of draft-lam-lime-summary-l0-l2-layer-independent.

So far, I, as a co-author of draft-lam..., have collected comments
among us and here are attached the comments as below.

I hope the comments will contribute the progress of
draft-tissa-lime-yang-oam-model.

Regards,

Yuji

------

Comments

This document defines the relationship of different OAM YANG model
that covers MPLS, IP, NVO3, TRILL and so on. But there seems to be
no Common OAM architecture for them, but the common OAM
architecture in this draft adapts those for Ethernet (IEEE802.1Q
and ITU-T G.8013/Y.1731) or MPLS-TP (RFC 6371).

Given that this draft covers only Ethernet and MPLS-TP OAM, it
would not have any issues. But how about other technologies like
IP or (IP/)MPLS? Do they use the architecture same as Ethernet or
MPLS-TP?

2. Common tools for OAM

The current draft only describes based on Ethernet CCM so that all
the parameters in the draft come basically from those for
configuring MEPs of Ethernet (and some for IPv4 and IPv6).

For the definition of Generic OAM, it is required to describe what
kind of the tool sets are considered in this draft.

Reading MEP in ietf-gen-oam, the MEP is regarded as bidirectional
end point that includes both generation process and reception
process.

ITU-T G.8052 (or ONF work for OAM) defines MEP that includes
generation process and reception process (i.e. Source and Sink).

In fact, Ethernet CCM works as one-way (called Dual-ended) so that
the clear distinction for MEP source and sink is defined in
G.8052.

Also co-located sink MEP in case of a bi-directional connection
should be considered.

4. Output in rpcs

Output in rpcs includes performance monitoring (i.e Delay
measurement, Loss measurement)related configuration data, But it
looks as a part of CC and CV functionalities.

As seen in ITU-T G.8013 (DM, LM, and Synthetic LM) and PM for
Trill OAM, the output (PM related configuration data) should be
regarded in more generic way.

output {

uses monitor-stats {

description

monitor sessions";

}

}

}

What does mean by "Stats of continuity check is same as that of
monitor sessions"?

5. Defect type

It describes as:

notifications:

:

The authors are interested in what kind of types are in for
defect-type.

In general, like section 4.4 (rpc), it is expected that the
detailed/clarified section for notification is added.

Three comments:

3. measure performance --> 3. monitor performance (loss,
delay).

(2) "The YANG data model presented in this document occurs at the
management layer."

should this be:

"The YANG data model presented in this document exists at
themanagement layer."

(3) The sentence in the last paragraph "This ability to go up and
down to different layers" is not a good description for "nesting".

Since the model is based on IEEE802.1Q, the expansion for MEP and
MIP should follow IEEE802.1Q.

Three comments:

(2) What is "rpc"? (expansion is missing) And note that both rpc
and RPC is used throughout the draft.

(3) The sentence "Under each MA, there can be two or more MEPs
"implies that the two MEPs are the source and sink of a
connection, Does this mean that for a bi-directional (transport)
connection there are two MAs?

It is suggested to move the first part (from:  The following
notations" until "leafs and leaf-lists ") to the front of section
4, because the notation is also used in sections 4.1... 4.4.

------

--
*****************************************************************
请记住，你是独一无二的，就像其他每一个人一样