Re: [Lime] WG Last Call

[Yuji Tochio <[e-mail]>]

Hi Michael.

Thanks for your reply.
Please see my further comments to 4, 5, 8, and 9, as marked <yt>..</yt>.
I am now fine with your other comments that I do not have below.

Thanks, Yuji

On 2016/07/05 16:17, wangzitao wrote:
>
> Hi Yuji,
>
> Thank you for reviewing this draft, and giving these valuable comments
>
> please find my answer in-line and tagger [zitao]
>
> Best Regards!
>
> -Michael
>
> -----邮件原件-----
>
> 发件人: Lime [mailto:[e-mail]] 代表Yuji Tochio
>
> 发送时间: 2016年7月4日13:37
>
> 收件人: [e-mail] <mailto:[e-mail]>
>
> 主题: Re: [Lime] WG Last Call
>
> 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
>
> [zitao]:The cfm out of the scope.
>
> And this suggestion work for me, I'd like to modify it in next version.
>
> 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.
>
> [zitao]:for the perform monitor:
>
> In case of Performance Monitoring Statistics are common between these technologies thus generic Yang model for Performance will be worked
>
> out through separate draft with Augmentation of Generic LIME model.
>
> In case of Other Function, it's technology specific and thus should be dealt in technology specific Yang model instead of Generic Model.
>
> 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.
>
> [zitao]: agree, I'd like to fix it in next version.
>
> 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.
>
> [zitao]: just because the different definition of mep id, the MEP-ID-format is considered. For example:
>
> -in trill, The MEPID associated with this MEP is the 2-octet RBridge Nickname[RFC7455];
>
> -and in mpls-tp, the LSP MEP ID consists of the 32-bit MPLS-TP Global_ID, the 32-bit Node Identifier, followed by the 16-bit Tunnel_Num, and the 16-bit LSP_NUM.
>
> Therefore the MEP-ID-format can help the model user to choose applicable MEP-ID, or add corresponding “MEP-ID case” into the “MEP-ID choice”.
>


<yt>
I would suggest the clarification above should be reflected in section 6.2.
</yt>


> 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?
>
> [zitao]: since the “MEP-ID” and “MEP-address” are choice/case node, it can not be used as the key value of the list[RFC6020]. Therefore we need a key(the 
> mep-name) to distinguish different MEP lists.
>

<yt>
I understand. The clarification above had better been added in section 4.3
</yt>

> 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.
>
> [zitao]: We support source and sink but use different name, for example, in RPC blocks, the “source” and “destination/sink” are defined.
>

<yt>
I am using source and sink as transmitting and receiving OAM packets and they are different from source and destination you are using.
In other words, if destination MEP has both transmitting and receiving processes, then they have source and sink as defined in G.8052.
Note that G.8013/Y.1731 uses initiating and peer MEP as you use for source and destination MEP.
</yt>

> 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.
>
> [zitao]: agree. It will be removed in next version.
>
> 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.
>
> [zitao]: agree. I’d like add some descriptions in next version.
>
> 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)
>
> [zitao]: It equivalent to “remote MEPs MAC in error state”.
>

<yt>
Does this error written in some RFCs? (If yes, please let me know)
</yt>

> - 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?
>
> [zitao]: thank you. I will add it in next version.
>
> And invalue looks typo, it should be invalid.
>
> [zitao]: thank you. I’d like to fix it in next version.
>
> - 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
>
> [zitao]: OK, I will add relative description in next version.
>
> 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.
>
> [zitao]: since in CC functions, a MIP is transparent to the ETH-CC information and therefore does not require any configuration information to support 
> ETH-CC[Y.1731].
>
> therefore we not define the address or ID in the base model. If the address and ID are needed to support loopback function, the model user can augment the MIP 
> list and add relative attributes.
>


<yt>
I do not mentioning CC functions, but connectivity-verification (Loopback) or traceroute function since the YANG module defines these fucntions.

And I have just found that the draft uses "continuity-verification" but this is wrong term.
It should be connectivity-verification (or continuity-check). See RFC 7276 please.

</yt>

> 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.
>
> [zitao]: thank you, I’ll fix it.
>
> ---------------------------------------------------------------
>
> 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] <mailto:[e-mail]>
>
> >https://www.ietf.org/mailman/listinfo/lime <https://www.ietf.org/mailman/listinfo/lime>
>
> >
>
> _______________________________________________
>
> Lime mailing list
>
> [e-mail] <mailto:[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/lime
>
>
>
> _______________________________________________
> Lime mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lime