Subject: [trill] Call for WG adoption of draft-yizhou-trill-active-active-connection-prob

From: Donald Eastlake <[email-masked]>
Date: Thu, 20 Feb 2014 11:13:55 -0500

This message begins a call for TRILL WG adoption of
draft-yizhou-trill-active-active-connection-prob-02.txt running
through the TRILL WG meeting early next month in London. Suggestions
for improvement are welcome and will, unless otherwise stated, be
interpreted as favoring adoption.

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

---

From: [email-masked]
Date: Tue, 25 Feb 2014 09:28:13 +0800

I think it is an important draft in the road to advance the active-active 
issue, and it looks fine to me.

So as one of the co-authors, I support the WG adoption.

Thanks,
Hongjun Zhai
---------------------------------------------
Add: No.68 Zijinghua Road, Yuhuatai District,
Nanjing City, R.P. China, 210012

Tel: +86 025 52877345
Email: [email-masked]
---------------------------------------------

Donald Eastlake <[email-masked]> 
发件人:  "trill" <[email-masked]>
2014-02-21 00:13

收件人
"[email-masked]" <[email-masked]>
抄送

主题
[trill] Call for WG adoption of 
draft-yizhou-trill-active-active-connection-prob

Thanks,
Donald

_______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: Haoweiguo <[email-masked]>
Date: Tue, 25 Feb 2014 02:38:26 +0000

Support as a co-author!
I think this draft clearly describes the goals and requirements for TRILL active-active connection.
thanks
weiguo
________________________________________
发件人: Donald Eastlake [[email-masked]]
发送时间: 2014年2月21日 0:13
收件人: [email-masked]
主题: [trill] Call for WG adoption of draft-yizhou-trill-active-active-connection-prob

Thanks,
Donald

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 26 Feb 2014 00:51:52 +0000

Hi,

I have read this draft. I think it covers most of the points that have been discussed in the TRILL WG. It is beneficial to design solution drafts taking this one as a baseline document. Hence, support for adoption.
I offer the following comments.

[page4] It says "RB2 (and other members of MC-LAG1) will not see that Hello from RB1." If RB1 and RB2 are connected through a LAN link as well, they will see each other's HELLO. So, "RB2 (and other members attached to the same MC-LAG) cannot exchange Hello on the MC-LAG." Or " RB2 (and other members of MC-LAG1) will not see that Hello from RB1 via the MC-LAG."

[page4] "... appointed forwarder mechanism is not applicable " this assertion appears twice. If an RBridge does not receive HELLOs from an VLAN interface, it will regarded itself as the AF on this interface. So, it' not accurate to say "appointed forwarder mechanism is not applicable". Maybe, we can say the appointed forwarder mechanism cannot work as expected.

[page5] s/For CE connecting/For a CE connecting/

[page5] s/to an CE/to a CE/

[page5] s/or name of MC-LAGs/or names of MC-LAGs/

[page6] s/a RB/an RB/

[page6] s/those port/those ports/

[page6] s/for all the member RB/for all the member RBs/

[page6] It says "This frame will be TRILL encapsulated and then forwarded through the campus to another member (say RB2) of the same MC-LAG. " This make me think the frame is destined to another member. Actually, RB2 is only one potential receiver of the multicast. There may be other remote receivers. I suggest we change it like this "This frame will be encapsulated as a multicast packet and forwarded to its receivers. Other member RBridge (say RB2) of the same MC-LAG will receive this multicast packet as well."

[page6] "As each of them thinks it is the appointed forwarder for all VLANs, without active-active changes they would all forward the frame to CE1." -> "As each of them thinks it is the appointed forwarder for _VLAN-x_, they would all _deliver_ the frame to CE1." {"active-active change" is not clear to us. Since this section is talking about "problems", we can also just remove this phrase.}

[page6] "In this case, without active-active changes RB2 will decapsulate the frame and forward it."-> "In this case, RB2 will decapsulate the _packet and egress_ it."

[page6] "it learns different address correspondence from the decapsulated data frames." -> "it learns different _attached RBridge nicknames_ from _decapsulating_ data _packet_."

[page7] It says "Most TRILL switches may behave badly under these circumstances and, for example, interpret this as a severe network problem." The phrase ", for example," should be removed.

[page7] s/go through the different paths/ go through different paths/

[page7] s/can be dropped/may be dropped/

[page7] The last paragraph of Section 3 looks like requirements rather than problem. How about we move it to section 4? And change the last sentient as follows. "Solutions of active-active connection at edge RBridges should carefully examine those features and make sure they work correctly." ->"...and make sure the unsynchronized information among member RBridges does not cause any conflict."

Thanks,
Mingui

>-----Original Message-----
>From: trill [mailto:[email-masked]] On Behalf Of Donald Eastlake
>Sent: Friday, February 21, 2014 12:14 AM
>To: [email-masked]
>Subject: [trill] Call for WG adoption of
>draft-yizhou-trill-active-active-connection-prob-02.txt running through the TRILL
>WG meeting early next month in London. Suggestions for improvement are
>welcome and will, unless otherwise stated, be interpreted as favoring adoption.
>
>Thanks,
>Donald
> 155 Beaver Street, Milford, MA 01757 USA  [email-masked]
>

---

From: Liyizhou <[email-masked]>
Date: Wed, 26 Feb 2014 02:19:58 +0000

Thanks Minggui. Please see inlines with [yz].

> From: trill [mailto:[email-masked]] On Behalf Of Mingui Zhang
> Sent: Wednesday, February 26, 2014 8:52 AM
> To: Donald Eastlake; [email-masked]
> Subject: Re: [trill] Call for WG adoption of draft-yizhou-trill-active-
> active-connection-prob
> 
> Hi,
> 
> I have read this draft. I think it covers most of the points that have
> been discussed in the TRILL WG. It is beneficial to design solution
> drafts taking this one as a baseline document. Hence, support for
> adoption.
> [page4] It says "RB2 (and other members of MC-LAG1) will not see that
> Hello from RB1." If RB1 and RB2 are connected through a LAN link as
> well, they will see each other's HELLO. So, "RB2 (and other members
> attached to the same MC-LAG) cannot exchange Hello on the MC-LAG." Or "
> RB2 (and other members of MC-LAG1) will not see that Hello from RB1 via
> the MC-LAG."
[yz]ok

> [page4] "... appointed forwarder mechanism is not applicable " this
> assertion appears twice. If an RBridge does not receive HELLOs from an
> VLAN interface, it will regarded itself as the AF on this interface. So,
> it' not accurate to say "appointed forwarder mechanism is not
> applicable". Maybe, we can say the appointed forwarder mechanism cannot
> work as expected.
[yz]ok. Will re-phrase

> [page6] s/for all the member RB/for all the member RBs/

[yz]will change accordingly for the above editorial comments

> [page6] It says "This frame will be TRILL encapsulated and then
> forwarded through the campus to another member (say RB2) of the same
> MC-LAG. " This make me think the frame is destined to another member.
> Actually, RB2 is only one potential receiver of the multicast. There
> may be other remote receivers. I suggest we change it like this "This
> frame will be encapsulated as a multicast packet and forwarded to its
> receivers. Other member RBridge (say RB2) of the same MC-LAG will
> receive this multicast packet as well."

[yz]Will re-phrase to remove ambiguity
 
> [page6] "As each of them thinks it is the appointed forwarder for all
> VLANs, without active-active changes they would all forward the frame
> to CE1." -> "As each of them thinks it is the appointed forwarder for
> _VLAN-x_, they would all _deliver_ the frame to CE1." {"active-active
> change" is not clear to us. Since this section is talking about
> "problems", we can also just remove this phrase.}
[yz] I think it is a basic problem description. I will re-phrase to remove ambiguity 

> [page6] "In this case, without active-active changes RB2 will
> decapsulate the frame and forward it."-> "In this case, RB2 will
> decapsulate the _packet and egress_ it."
[yz] ok

> [page6] "it learns different address correspondence from the
> decapsulated data frames." -> "it learns different _attached RBridge
> nicknames_ from _decapsulating_ data _packet_."
[yz]Will re-phrase to remove ambiguity

> [page7] It says "Most TRILL switches may behave badly under these
> circumstances and, for example, interpret this as a severe network
> problem." The phrase ", for example," should be removed.
[yz]ok 
> [page7] s/go through the different paths/ go through different paths/
[yz]ok  
> [page7] s/can be dropped/may be dropped/
[yz]ok  
> [page7] The last paragraph of Section 3 looks like requirements rather
> than problem. How about we move it to section 4? And change the last
> sentient as follows. "Solutions of active-active connection at edge
> RBridges should carefully examine those features and make sure they
> work correctly." ->"...and make sure the unsynchronized information
> among member RBridges does not cause any conflict."
[yz]Will re-phrase. I prefer to keep it in section 3 to make the paragraph more complete.

Yizhou

> through
> >the TRILL WG meeting early next month in London. Suggestions for
> >improvement are welcome and will, unless otherwise stated, be