Subject: Re: [trill] some comments on the smartnode draft.

From: [email-masked]
Date: Mon, 18 Nov 2013 10:53:14 +0800

Sorry for the delay reply. My comments is inline.

1. When two smartnodes that attached to same a hybrid link, want to 
exchange frames, they employ the native form or the TRILL-encapsulated 
form of the frames? 
// For simplification,the smart endnode acts as normal endnode on the 
hybrid link. So if there are smart endnodes and normal endnodes attached 
to the same port, they exchange the native frame.

2. On a hybrid link, when one smartnode transmit multicast traffic, other 
smartnodes on this link will receive duplicating traffic, one is 
TRILL-encapsulted and the other is native traffic(decapsulated by the AF 
attached to this link). Should the deplication need to be avoided or not? 
How to avoid that duplication? 
//Also it should be the native form for avoiding duplicating traffic.

3. In the multi-homing section, smartnode uses a "multi-homed bit" to tell 
remote egress RB to accept more than one entries for same a MAC. If the 
remote RB does not know this bit, how it will do? Is some decription of 
backward compatibilty needed in this draft? Is this section still left in 
this draft or removed to a furture draft that discuss active-active 
solution specially? Suggest to move it to the future draft to get a 
unified solution for active-active connectivity. 
// The multihoming in this draft would be very simple. Smart endnode only 
uses one of the edge RBridge's nickname.

ZhaiHongJun129567/user/zte_ltd 
2013-11-08 10:39

收件人
Radia Perlman <[email-masked]>, [email-masked], 
[email-masked], [email-masked], [email-masked]
抄送
"[email-masked]" <[email-masked]>
主题
some comments on the smartnode draft.

Hi authors, 

1. When two smartnodes that attached to same a hybrid link, want to 
exchange frames, they employ the native form or the TRILL-encapsulated 
form of the frames? 

2. On a hybrid link, when one smartnode transmit multicast traffic, other 
smartnodes on this link will receive duplicating traffic, one is 
TRILL-encapsulted and the other is native traffic(decapsulated by the AF 
attached to this link). Should the deplication need to be avoided or not? 
How to avoid that duplication? 

3. In the multi-homing section, smartnode uses a "multi-homed bit" to tell 
remote egress RB to accept more than one entries for same a MAC. If the 
remote RB does not know this bit, how it will do? Is some decription of 
backward compatibilty needed in this draft? Is this section still left in 
this draft or removed to a furture draft that discuss active-active 
solution specially? Suggest to move it to the future draft to get a 
unified solution for active-active connectivity. 

Thanks, 
Hongjun Zhai

---

From: [email-masked]
Date: Mon, 18 Nov 2013 11:34:03 +0800

Hi,

My comments are incline and marked with [Hongjun].

Thanks,
Hongjun Zhai

[email-masked] 
发件人:  [email-masked]
2013-11-18 10:53

收件人
[email-masked]
抄送
[email-masked], [email-masked], [email-masked], 
Radia Perlman <[email-masked]>, "[email-masked]" <[email-masked]>
主题
Re: [trill] some comments on the smartnode draft.

[Hongjun] Native frame is a clever choice, and make it clear in the draft 
please.

[Hongjun] OK.

[Hongjun] If smarnode S multi-homed to R1 and R2, which nickname should it 
use when it transmits outgoing multicast traffic to TRILL campus?

收件人

Hi authors, 

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