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

From: [email-masked]
Date: Mon, 18 Nov 2013 15:12:36 +0800

> When E is sending multidestination, it should send via R1 for RPF 
reason. 

Let unicast aside, and focus on the multicast traffic. In the following 
scenario (where E multi-homed to R1 and R2 through a physical switch), how 
to avoid E's multicast traffic to be egressed by R2 after the traffic has 
traveled around the path E->R1->TRILL campus->R2? If cannot be avoided, F 
will receive duplication multicast traffic (one copy from E directly, and 
the other is the traffic egressed by R2). 

  ............... 
 :               : 
 : TRILL campus  : 
  . ............. 
    |          | 
  +----+     +----+ 
  | R1 |-----| R2 | 
  +----+     +----+ 
     \        / 
      \      / 
       \    / 
      +-------+ 
      |switch | 
      +-------+ 
        |   | 
      E O   O F

By the way, I believe multi-homing(or active-active) is not an easy issue, 
so I suggest that it  should be included in Trill active/active edge 
rather than in this draft.

Thanks,
Hongjun Zhai

胡方伟175772/user/zte_ltd
2013-11-18 13:57

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

If smart endnode E is attached to R1 and R2. E always encapsulates using 
R1's nickname. The 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 R1 for RPF reason.

ZhaiHongJun129567/user/zte_ltd
2013-11-18 11:34

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

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.

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. 
[Hongjun] Native frame is a clever choice, and make it clear in the draft 
please. 

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. 
[Hongjun] OK.

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. 
[Hongjun] If smarnode S multi-homed to R1 and R2, which nickname should it 
use when it transmits outgoing multicast traffic to TRILL campus?

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 _______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: [email-masked]
Date: Mon, 18 Nov 2013 15:04:04 +0800

reason.

Let unicast aside, and foucus on the multicast traffic. In the following 
scenario (where E multi-homed to R1 and R2 through a physical switch), how 
to avoid E's multicast traffic to be egressed by R2 after the traffic has 
traveled around the path E->R1->TRILL campus->R2? Then F will receive 
duplication multicast traffic(one copy from E directly, and the other is 
the traffic egressed by R2).

  ...............
 :               :
 : TRILL campus  :
  . .............
    |          |
  +----+     +----+
  | R1 |-----| R2 |
  +----+     +----+
     \        /
      \      /
       \    /
      +-------+
      |switch |
      +-------+
        |   |
      E O   O F

By the way, I believe multi-homing(or active-active) is not an easy issue, 
so I suggest that the multi-homing staff should be included in Trill 
active/active edge rather than in this draft.

Thanks,
Hongjun Zhai

胡方伟175772/user/zte_ltd
2013-11-18 13:57

收件人
翟洪军129567/user/zte_ltd
抄送

收件人
[email-masked]
抄送

Hi, 

Thanks, 
Hongjun Zhai 

[email-masked] 

收件人
[email-masked] 
抄送

收件人

Hi authors, 

Thanks,

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 20 Nov 2013 01:29:25 +0000

Yes. It's not trivial to design a Active/Active scheme which avoids duplications and loops for multicast traffic.

Two years ago, we proposed this:

   "When a multicast frame originated by the local link is forwarded
   across the TRILL network and received by the peer RBridge, it is
   important that the peer RBridge does not egress this frame back to
   the local link, otherwise it will cause a forwarding loop to the
   local link."

This issue can be solved using the well known "split-horizon" technique. That's one of the important reasons why the pseudonode solution was proposed for TRILL Active/Active.

Thanks,
Mingui

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: Monday, November 18, 2013 3:04 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked];
>[email-masked]; Radia Perlman; [email-masked]; [email-masked]
>Subject: Re: [trill] some comments on the smartnode draft.
>
>
>> When E is sending multidestination, it should send via R1 for RPF reason.
>
>Let unicast aside, and foucus on the multicast traffic. In the following scenario
>(where E multi-homed to R1 and R2 through a physical switch), how to avoid E's
>multicast traffic to be egressed by R2 after the traffic has traveled around the
>path E->R1->TRILL campus->R2? Then F will receive duplication multicast
>traffic(one copy from E directly, and the other is the traffic egressed by R2).
>
>  ...............
> :               :
> : TRILL campus  :
>  . .............
>    |          |
>  +----+     +----+
>  | R1 |-----| R2 |
>  +----+     +----+
>     \        /
>      \      /
>       \    /
>      +-------+
>      |switch |
>      +-------+
>        |   |
>      E O   O F
>
>
>By the way, I believe multi-homing(or active-active) is not an easy issue, so I
>suggest that the multi-homing staff should be included in Trill active/active edge
>2013-11-18 13:57 收件人
>Re: Re: [trill] some comments on the smartnode draft.链接
><Notes://NJMAIL07/482575E6002F4059/F642F2D152FB45B248256C52004478D
>5/D83196061359124148257C27001093C9>
>
>
>
>
>
>If smart endnode E is attached to R1 and R2. E always encapsulates using R1's
>nickname. The 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 R1 for RPF reason.
>
>
>
>
>2013-11-18 11:34 收件人
>Re: [trill] some comments on the smartnode draft.链接
><Notes://HKMAIL02/482578F6002B88D3/724F11FA6E88DFBA482575D8003285
>D9/A2D3B79D24D2A77048257C27000FEA7B>
>
>
>
>
>
>
>
>Hi,
>
>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.
>[Hongjun] Native frame is a clever choice, and make it clear in the draft please.
>
>
>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?
>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.
>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?
>
>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?
>
>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,

---

From: Radia Perlman <[email-masked]>
Date: Wed, 20 Nov 2013 13:56:59 -0800

I've been travelling so haven't read this thread as carefully as I should
have before commenting, but here's a thought...

It does seem to add complexity to have a port that has both smart and dumb
endnodes, if the smart endnodes need to learn from data.  With Linda
Dunbar's "learn only from a directory" endnodes, smart endnodes are much
simpler....but require a directory...so it would be nice to allow
learn-from-data smart endnodes as well.

So...what if we just disallowed having a mixture of smart
learning-from-data endnodes and dumb endnodes on the same link?  I'm not
sure that would be a big loss of functionality, and I think it makes the
design simpler.  So for instance, if the TRILL switch port were configured
with "smart data-learning endnodes on this port", the TRILL switch would
leave everything encapsulated on that port all the time.

If there were bridges on the link so it really was a shared link, and there
was a dumb endnode on a link configured for smart data-learning endnodes,
then that endnode would be ignored, this case would be detected right away
(perhaps with the RB notice "why am I seeing native traffic on this link
when it's configured for smart data-learning endnodes), and would not cause
any problems to the campus beyond the ignored dumb endnode.

Radia

On Tue, Nov 19, 2013 at 5:29 PM, Mingui Zhang <[email-masked]>wrote:

> Yes. It's not trivial to design a Active/Active scheme which avoids
> duplications and loops for multicast traffic.
>
> This issue can be solved using the well known "split-horizon" technique.
> That's one of the important reasons why the pseudonode solution was
> proposed for TRILL Active/Active.
>
> Thanks,
> Mingui
>
> scenario
> >Radia Perlman <[email-masked]>, "[email-masked]" <[email-masked]
> >,
> >[email-masked]
> >主题
> R1's
> >Radia Perlman <[email-masked]>, "[email-masked]" <[email-masked]
> >,
> >[email-masked]
> >主题
> exchange
> hybrid
> TRILL-encapsulted
> backward
> exchange
> TRILL-encapsulted
> backward