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

From: Donald Eastlake <[email-masked]>
Date: Fri, 7 Mar 2014 13:30:41 -0500

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

---

From: "Saravanan Arunachalam (saarunac)" <[email-masked]>
Date: Wed, 12 Mar 2014 20:06:01 +0000

+1 support the document

Regards
-Arun

-----Original Message-----
From: trill [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Friday, March 07, 2014 10:31 AM
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 12 Mar 2014 20:27:07 +0000

+1 support as co author

-----Original Message-----
From: trill [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Friday, March 07, 2014 10:31 AM
To: [email-masked]
Subject: [trill] WG Last Call - draft-ietf-trill-oam-fm

Hi,

Thanks,
Donald and Jon

---

From: Gurumukh Singh Tiwana <[email-masked]>
Date: Wed, 12 Mar 2014 13:30:20 -0700

I support the document

Gurumukh

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 12 Mar 2014 22:31:49 +0200

+1 support
I believe this draft is ready for publication.

Tal.

-----Original Message-----
From: trill [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Friday, March 07, 2014 8:31 PM
To: [email-masked]
Subject: [trill] WG Last Call - draft-ietf-trill-oam-fm

Hi,

Thanks,
Donald and Jon

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 13 Mar 2014 07:19:37 +0000

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;
2) Suggest to change the order between section 8 and section 9;
3) TRILL OAM Specific TLVs names in section 8.4.2 are not consistent with the following draft;
4) In section 9.2.1, "The TRILL OAM Version TLV" should be "The TRILL OAM Application Identifier TLV"?

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

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)? 
2) What's the reason MEP transmits 4 CCM messages per each flow?
3) The numbered CCM messages possibly arrive remote MEP out of order because the multi-path characteristics of TRILL;
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 judgement. For example, when  MEP-B does not receive CCM messages of 3,4,5,6.

B.R.
Frank

> Sent: Saturday, March 08, 2014 2:31 AM
> To: [email-masked]
> 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
>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 14 Mar 2014 03:17:42 -0400

I did a careful review of the draft and have the following suggestions:

Section 3: This section correctly says that the TRILL Ethertype is
really part of the link header on Ethernet links; however, that means
that the length of the basic TRILL header is 6 bytes, not 8 bytes. So
"8" should be changed to "6" in Figure 1 and in the text on the TRILL
Header below that figure.

Section 3.3 at the end, looks like a "B" and an "F" got swapped. I think
OLD
   Capability flags "A" and "B" are defined by [rfc6326bis] and
   [rfcFGL]. "O" and "F" Flags are located after "F" flag in the
NEW
   Capability flags "A" and "F" are defined by [rfc6326bis] and
   [rfcFGL]. "O" and "B" Flags are located after "F" flag in the

Section 4.3.2: Most of 4.3 looks reasonable but the 2nd top level
bullet in 4.3.2 seems to specify that OAM frames be egressed and any
other TRILL Data frame addressed to the local nickname be discarded.
Maybe I'm confused, but what about regular user data...

Section 4.4: I think a two instances where it says "If MEP or MIP is
configured on the Inner.VLAN ..." should says "If MEP or MIP is
configured on the inner VLAN/FGL ..."

Section 4.4:  At one point it says "Non OAM l Packet". Perhaps that
should just be " Non-OAM Packet"

Section 8.4.2: Add one more line to the list of TLV types:
    TBDk         Authentication TLV

Minor Editorial/Typos:

Section 3.2: "RFC6325" should be "[RFC6325]" although "RFC 6325" would
also be OK.

Section 3.3: Just before the Section 4 header, missing "is". Should say
   Usage of "O" and "B" bits flags is discussed above.

Section 8.4.13: top of page 36, "in which case he process" -> "in
which case the process"
                         "using the Key ID space as" -> "using the
same Key ID space as"

Section 11.1: At end, "the Opcodes used is." -> "the Opcode used is TBD4."

Section A.2: "RBrdige" -> "RBridge"

Appendix B: A comment in multiple square brackets that is no longer
true got left in and should be deleted.

Appendix B: "shirt" -> "short"

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 14 Mar 2014 15:29:50 +0000

Hi Donald

Thanks for the comments will follow through and update the draft accordingly.

Thanks
Tissa

-----Original Message-----
From: trill [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Friday, March 14, 2014 12:18 AM
To: [email-masked]
Subject: Re: [trill] WG Last Call - draft-ietf-trill-oam-fm

Section 3: This section correctly says that the TRILL Ethertype is really part of the link header on Ethernet links; however, that means that the length of the basic TRILL header is 6 bytes, not 8 bytes. So "8" should be changed to "6" in Figure 1 and in the text on the TRILL Header below that figure.

Section 3.3 at the end, looks like a "B" and an "F" got swapped. I think OLD
   Capability flags "A" and "B" are defined by [rfc6326bis] and
   [rfcFGL]. "O" and "F" Flags are located after "F" flag in the NEW
   Capability flags "A" and "F" are defined by [rfc6326bis] and
   [rfcFGL]. "O" and "B" Flags are located after "F" flag in the

Section 4.3.2: Most of 4.3 looks reasonable but the 2nd top level bullet in 4.3.2 seems to specify that OAM frames be egressed and any other TRILL Data frame addressed to the local nickname be discarded.
Maybe I'm confused, but what about regular user data...

Section 4.4: I think a two instances where it says "If MEP or MIP is configured on the Inner.VLAN ..." should says "If MEP or MIP is configured on the inner VLAN/FGL ..."

Section 4.4:  At one point it says "Non OAM l Packet". Perhaps that should just be " Non-OAM Packet"

Minor Editorial/Typos:

Section 3.2: "RFC6325" should be "[RFC6325]" although "RFC 6325" would also be OK.

Section 8.4.13: top of page 36, "in which case he process" -> "in which case the process"
                         "using the Key ID space as" -> "using the same Key ID space as"

Appendix B: A comment in multiple square brackets that is no longer true got left in and should be deleted.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA  [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 14 Mar 2014 13:48:50 -0400

Hi Tissa,

OK. I'm in the United Club at SFO about to fly to Beijing for a week
for the IEEE 802 meeting.

Suggest you edit in appropriate changes from my email and others,
unless there are objections, but probably best not to post another
version until WG Last Call ends 24 March.

Thanks,
Donald

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 14 Mar 2014 17:56:13 +0000

Hi Donald

I have only your edits, did I miss something ?

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Friday, March 14, 2014 10:49 AM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked]
Subject: Re: [trill] WG Last Call - draft-ietf-trill-oam-fm

Hi Tissa,

OK. I'm in the United Club at SFO about to fly to Beijing for a week for the IEEE 802 meeting.

Suggest you edit in appropriate changes from my email and others, unless there are objections, but probably best not to post another version until WG Last Call ends 24 March.

Thanks,
Donald

On Fri, Mar 14, 2014 at 11:29 AM, Tissa Senevirathne (tsenevir) <[email-masked]> wrote:
>> 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
>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 14 Mar 2014 14:18:57 -0400

I guess at this point there is just
http://www.ietf.org/mail-archive/web/trill/current/msg06177.html

Thanks,
Donald

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 14 Mar 2014 12:50:39 -0700

TRILL OAM FM is long overdue. We have come a long way to come to this
point. Having this comprehensive doc detailing complete OAM solution is
very much needed for interoperability and deployment of TRILL technology.
As a co-author, I feel that document is ready and would like to see this
document published as RFC.

-sam

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 27 Mar 2014 03:41:19 +0000

Hi draft authors,
I have posted my comments on this draft about two weeks ago as followed, but I get no response until now.
So, I send this email again to remind you all. Hoping to get your response.
Thanks!

B.R.
Frank

> From: Xialiang (Frank)
> Sent: Thursday, March 13, 2014 3:20 PM
> To: 'Donald Eastlake'
> Cc: [email-masked]
> 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:
> 3) The numbered CCM messages possibly arrive remote MEP out of order
> because the multi-path characteristics of TRILL;
> 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 judgement. For
> example, when  MEP-B does not receive CCM messages of 3,4,5,6.
> 
> B.R.
> Frank
>

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Thu, 27 Mar 2014 05:59:29 +0000

Hi Frank

Sincere apologies, this fell through cracks. Will answer no later than Monday 3/31 PST.

Thanks for he comments,
Tissa

-----Original Message-----
From: trill [mailto:[email-masked]] On Behalf Of Xialiang (Frank)
Sent: Wednesday, March 26, 2014 8:41 PM
To: Tissa Senevirathne (tsenevir); Norman Finn (nfinn); Samer Salam (ssalam); Deepak Kumar (dekumar); Donald Eastlake; [email-masked]; Liyizhou
Cc: Donald Eastlake; [email-masked]
Subject: [trill] comments on this draft://RE: WG Last Call - draft-ietf-trill-oam-fm

Hi draft authors,

B.R.
Frank

> 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;
> 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 
> judgement. For example, when  MEP-B does not receive CCM messages of 3,4,5,6.
> 
> B.R.
> Frank
>

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Sat, 29 Mar 2014 21:03:06 +0000

Frank

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

-----Original Message-----
From: trill [mailto:[email-masked]] On Behalf Of Xialiang (Frank)
Sent: Thursday, March 13, 2014 12:20 AM
To: Donald Eastlake
Cc: [email-masked]
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.

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

[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

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Mon, 31 Mar 2014 03:01:11 +0000

Tissa
I agree with your clarification. One more suggestion: For clarity, some words need to be added to describe how to ensure all CCMs belonging to a flow to go through the same path.

B.R.
Frank

> From: Tissa Senevirathne (tsenevir) [mailto:[email-masked]]
> Sent: Sunday, March 30, 2014 5:03 AM
> To: Xialiang (Frank); Donald Eastlake
> Cc: [email-masked]
> 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.
> 
> [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.
> 
> [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.
> 
> 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.
> 
> scheme seems to be not correct totally and will give fault judgment. For
> [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
>

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 31 Mar 2014 19:04:13 +0000

Hi Frank

I will add something like the following in to section 12.

Path monitored by CCM in TRILL depends on the flow entropy of the CCM message. Hence in TRLL or any other multipath environment, CCM monitors connectivity and cross connect errors per flow.

-----Original Message-----
From: Xialiang (Frank) [mailto:[email-masked]] 
Sent: Sunday, March 30, 2014 8:01 PM
To: Tissa Senevirathne (tsenevir); Donald Eastlake
Cc: [email-masked]
Subject: RE: [trill] WG Last Call - draft-ietf-trill-oam-fm

Tissa

B.R.
Frank

> problem also exists other place in the draft; [Tissa] Thanks and will fix them.
> 
> 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.
> 
> [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.
> 
> 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.
> 
> 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