Re: [Lime] WG Last Call

[Yuji Tochio <[e-mail]>]

Dear authors of the draft,

Here are my comments/questions to draft-ietf-lime-yang-oam-model-06.
I am glad these comments are considered.

Regards, Yuji

---------------------------------------------------------------
1) Base mode [section 4]

The text says:
"Base mode for other technologies such as MPLS-TP
and future extensions will be defined in their
corresponding documents."

I am worrying what other technologies except MPLS-TP mean.

Is Base Mode for Ethernet CFM (802.1Q or G.8013) out of
the scope (or N/A)?  If Yes, need to clarify in section 4
like replacing

other technologies such as MPLS-TP and future extensions

by

other technologies and future extensions developed in IETF


2) PM (Performance Monitoring)

PM aspects are missing.
In my understanding, draft-wang-lime-yang-pm will be
incorporated but the current draft (lime-yang-oam) is not.
I would like to address this draft should be completed
after PM parts are completed.


3) MP and MEP [section 4.3]

In general, it seems that the this YANG module is mixing
MEP for Ethernet/MPLS-TP and MP for TRILL and make it MEP
for LIME.

In TRILL OAM, mp-address is defined for/within source-MEP
and destination-MEP, but the idea of source-MEP and
destination-MEP does not entirely suit to Ethernet.

It is noted that source-MEP and destination-MEP is local
terminologies of MEP found only in TRILL.
Please see [IEEE802.1Q] and [ITU-T G.8013/Y.1731] or [G.8001]
how xxx MEP(s) is(are) defined.

And MP Addressing in RFC 7147 is somehow different from [802.1Q].

So far modeling for MEP and MP (including rpc) should be
considered on this point, i.e. not mixing MEP for Ethernet
and MP for TRILL.


4) MEP ID/MEP name [section 4.3]

In section 4.3, MEPs are represented as mep-name, MEP-ID, and
mp-address (mep address).
I am still confused why these 3 attributes are considered.

Per [802.1Q] and [G.8013/Y.1731], it is true for MEP ID defined as:
- MEP ID is a 2-octet field where the 13 least significant bits
are used to identify the MEP transmitting the CCM frame. MEP ID
is unique within the MEG. (ITU-T G.8013 9.2.1)
- Each individual MEP is configured with a MEPID that is unique
within that MA. (IEEE802.1Q 19.2.1)
It is noted that the type for mep-id is int32.

And I am not sure  why MEP-ID-format is also required as well.

Mep-name defines "Generic administrative name of the MEP" in the
YANG module and section 4.3 says it is used for indexing MEP.
I understand the usage, but is it really required to use
mep-name for configuration MEP?


5) Configuration data structure for MEP

Reading MEP in ietf-conn-oam, the MEP is regarded as bidirectional
end point that includes both generation process and reception process.
[G.8052] 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].

A good example is period (transmit-interval in this draft).
To works the CC mechanism, the configuration both for transmit and
reception. The configuration of reception is used for defect for
LoC and unexpected Period.

This draft should consider MEP source and sink.
An impact of this issue leads to the support of dual-ended OAM tools
and/or OAM tools for performance monitoring.


6) Default MD-LEVEL

Section 6.3 of the draft says "Default MD-LEVEL is set to 3".
This seems come from [802.1Q] but the value depends on the
architecture of network service.

Actually, but the has some inconsistency with MEL modeling
in ITU-T G.8052 that provides IM for Ethernet OAM.
G.8052 defines the management of MEP based on G.8013/Y.1731,
that a MEP with MEL = 7 corresponds to the NCM MEP and a
MEP with other MEL values are considered as TCM MEP.
(NCM/TCM: Network/Tandem Connection Monitoring)

So the proposed is remove the sentence in 6.3.


7) TTL usage for CV (connectivity verification)

How about the default value for mpls-ttl?

RFC 6426 says:
In order for the on-demand CV packet to be processed
at the desired MIP, the TTL of the MPLS label MUST be set such
that it expires at the MIP to be probed.

It is also applicable to use 255, same as IP, so it looks hard
to define the default value.

But it is better to describe how to set the TTL. The description
may help this.


8) defect-types

Some defect-types are defined. I am confused by these errors.
Following comments are some examples:

- remote-mep-error

It says:
"Indicates that one or more of the remote MEPs is reporting a failure"

Do(es) MEP(s) report the failure to peer MEP for the MEP(s) or to EMF?
Given that it is the latter case, why does it differentiated from the
peer MEP to the MEP(s).
Or is it an error related to validation fail? (RFC 6426)

- invalue-oam-error

It says:
  "Indicates that one or more invalid OAM messages has been
received and that 3.5 times that OAM message transmission
interval has not yet expired."

First, this will be equivalent to  5.1.1.2 to 5.1.1.4 in RFC 6371,
and 5.1.1.1 (dLOC) is missing.
Is it (not including LOC) intentional?

And invalue looks typo, it should be invalid.

- cross-connect-error

It says:
"Indicates that one or more cross-connect oam messages has been
received and that 3.5 times that OAM message transmission
interval has not yet expired.

Please clarify what "one or more cross-connect oam messages" means


9) MIP modeling

I am not sure why and how MIP is modeled as:

   grouping MIP {
     description
       "defines MIP";
     leaf interface {
       type if:interface-ref;
       description
          "Interface";
     }
   }

At least, MIP address and ID (and name?) may be required for CV
(Loopback) functions. I would like to ask for clarification.


10) Terminology

    MEP   - Maintenance End Point [RFC7174] [IEEE802.1Q] [RFC6371].

    MIP   - Maintenance Intermediate Point [RFC7174] [IEEE802.1Q]
          [RFC6371].

These 3 references above define different abbreviation for MEP and MIP.

---------------------------------------------------------------

On 2016/06/24 2:56, Ronald Bonica wrote:
> Folks,
>
> This message begins a WG last call for draft-ietf-lime-yang-oam-model-06. Last call ends on July 7, 2016.
>
>                                    Ron
>
> _______________________________________________
> Lime mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lime
>