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

From: [email-masked]
Date: Fri, 8 Nov 2013 10:39:41 +0800

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: Mingui Zhang <[email-masked]>
Date: Tue, 12 Nov 2013 09:40:27 +0000

Hi,

I have read the draft. A smart node volunteers to do some job on behalf of an RBridge, e.g., encapsulation/decapsulation, performing directory query tasks, filtering the MAC address based on session (E-D), etc. This can be useful and I support it.

One endnode E (whether it is a server, hypervisor, or VM) can serve multiple RBridges as different smart nodes. I guess this point may be discussed in the draft.

I second to Hongjun that the multi-homing staff should be included in Trill active/active edge.

By the way,  I wonder whether the "MAC address coexist" thing is supported by existing silicon?

Thanks,

Mingui

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, November 08, 2013 10:40 AM
To: Radia Perlman; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [trill] 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: Wed, 13 Nov 2013 15:07:06 +0800

[hfw] Hi, Minggui,thanks for your comments

Please see my comments inline.

I have read the draft. A smart node volunteers to do some job on behalf of 
an RBridge, e.g., encapsulation/decapsulation, performing directory query 
tasks, filtering the MAC address based on session (E-D), etc. This can be 
useful and I support it.
//[hfw]  Thanks.
 
One endnode E (whether it is a server, hypervisor, or VM) can serve 
multiple RBridges as different smart nodes. I guess this point may be 
discussed in the draft.

//[hfw]  Good suggestion. 
 
I second to Hongjun that the multi-homing staff should be included in 
Trill active/active edge.

//Multi-homing in this draft would be very simple. Smart Endnode only uses 
one of the edge RBridge's nickname. Say that smart endnode E is attached 
to R1 and R2. E could always 
encapsulate using R1's nickname. T      he traffic to TRILL campus can 
load split on both its links, while the return traffic to E will always go 
via R1.
When E is sending multidestination, it should send via R for RPF reason.
 
By the way,  I wonder whether the "MAC address coexist" thing is supported 
by existing silicon?

// [hfw] I know that there are silicons to support the "MAC address ECMP".

Mingui Zhang <[email-masked]> 
发件人:  [email-masked]
2013-11-12 17:40

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

Hi,
 
I have read the draft. A smart node volunteers to do some job on behalf of 
an RBridge, e.g., encapsulation/decapsulation, performing directory query 
tasks, filtering the MAC address based on session (E-D), etc. This can be 
useful and I support it.
 
One endnode E (whether it is a server, hypervisor, or VM) can serve 
multiple RBridges as different smart nodes. I guess this point may be 
discussed in the draft.
 
I second to Hongjun that the multi-homing staff should be included in 
Trill active/active edge.
 
By the way,  I wonder whether the "MAC address coexist" thing is supported 
by existing silicon?
 
Thanks,
Mingui

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Friday, November 08, 2013 10:40 AM
To: Radia Perlman; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: [trill] some comments on the smartnode draft.

Hi authors, 

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

---

From: [email-masked]
Date: Wed, 13 Nov 2013 15:40:41 +0800

Hi,

I have read this draft, and found some questions. I post them on November 
08, but have not got any response, so I repeat them as follows, and hope 
to get answer this time.

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 or not support "MAC address coexist", 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?

Thanks，
Hongjun Zhai

[email-masked] 
2013-11-13 15:07

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

  

//[hfw]  Good suggestion. 

  

收件人

Hi, 

  

Thanks, 
Mingui 

Hi authors, 

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