Re: [trill] WG Last Call - draft-ietf-trill-oam-fm

Frank

Thanks for going through the draft and careful review. Please see in -line the answers

-----Original Message-----
From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Xialiang (Frank)
Sent: Thursday, March 13, 2014 12:20 AM
To: Donald Eastlake
Cc: trill@ietf.org
Subject: Re: [trill] WG Last Call - draft-ietf-trill-oam-fm

Hi draft authors,
After reviewing this draft, I think it's a very important framework draft and organized well. I support it with several comments below:
1. Several typos:
1) header format of section 8, section 9.2 are not correct. Similar problem also exists other place in the draft;
[Tissa] Thanks and will fix them.

2) Suggest to change the order between section 8 and section 9;

[Tissa] What do you mean by changing the order ? You mean to swap 8 and 9 ? If so I am not clear why. Section 8 is the explanation of general TLVs, Section 9 is operation of Loopback message. Before explaining the mechanics of Loopback message we need explain the associated TLVs. Section 10 is Path trace message. 

3) TRILL OAM Specific TLVs names in section 8.4.2 are not consistent with the following draft;
[Tissa] Thanks for noting that, will fix in the next edition.

4) In section 9.2.1, "The TRILL OAM Version TLV" should be "The TRILL OAM Application Identifier TLV"?
[Tissa] Thanks will fix it.

2. In section 1, is reference to [TRLOAMFRM] ok because it's not a WG draft or RFC?
[Tissa] Correct

3. In section 12:
1) what's is the main goal of it? Detecting flow fault or path fault of multi-path (e.g. ECMP)? 
[Tissa] CCM js transmitted with a specific flow. Hence CCM detect per flow fault.

2) What's the reason MEP transmits 4 CCM messages per each flow?
[Tissa] 802.1ag section 20.1 Continuity Check Protocol, specifies loss of 3 consecutive messages triggers a fault. Hence we have decided to transmit 4 messages and loss of any 3 consecutive to detect the fault. This number 3 is hard coded in 802.1ag and we are proposing to use exactly the same. There is a reason for this hard coding. The reason is that in large networks maintaining consistent configuration is hard hence this parameter is kept constant. If one want to tune the CCM then can play with transmission intervals.

3) The numbered CCM messages possibly arrive remote MEP out of order because the multi-path characteristics of TRILL;
[Tissa] CCM path is governed by the flow entropy. So it is per flow behavior. If a flow arrive out of order means the data that it is mimicking is also out of order. Which in turn is a valid fault.  Multipathing cannot make data of a given flow out of order and should ensure in order delivery of packet per flow.

4) Even if CCM messages can arrive remote MEP in order, the fault detecting scheme seems to be not correct totally and will give fault judgment. For example, when  MEP-B does not receive CCM messages of 3,4,5,6.

[Tissa] no it will not. Because, as explained above it is per flow that we are monitoring. So 1,2,3,4 are flow-1 and 5,6,7,8 are flow-2.  You have received 1,2 of flow-1 and 7,8 of flow-2 which qualifies as valid flow path.

B.R.
Frank

> -----Original Message-----
> From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Donald 
> Eastlake
> Sent: Saturday, March 08, 2014 2:31 AM
> To: trill@ietf.org
> Subject: [trill] WG Last Call - draft-ietf-trill-oam-fm
> 
> Hi,
> 
> As announced at the TRILL WG meeting today, this starts a WG Last Call 
> on draft-ietf-trill-oam-fm-02.txt running through March 24th.
> 
> Thanks,
> Donald and Jon
> 
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill

_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill