Subject: [trill] [TRILL] A comment on draft-hao-trill-analysis-active-active-01

From: hongjun ZHAI <[email-masked]>
Date: Wed, 19 Feb 2014 21:38:40 +0800

Hi authors,

I reviewd the draft and found it gives a good analysis to the solutions for
TRILL active-active issue. And a comment on it.

In Section 5.1.2, a "Centralized Replication" method is given to fix the
RPFC issue of the Pseudo-nickname(or Virtual RBridge, RBv) solution.
According this method, when a member RBridge(say RBi) of a RBv receives BUM
traffic, it unicasts the traffic to the root of a distribution tree, say
RBn. Then RBn re-encapsulates the traffic with RBi's nickname as
ingress nickname in the new TRILL header and forwards it along a tree. But
there is still RFPC issue unresoved in this method.

For exampel, in the following tree topology, where RB1 is the ingress
RBridge of RBv, RB4 is the root of the tree.

            +-----+
            | RB4 |
            +-----+
            /    \
           /      \
      +-----+   +-----+
      | RB2 |   | RB3 |
      +-----+   +-----+
        |
     +-----+
     | RB1 |
     +-----+

When receiving a BUM traffic, RB1 unicasts it to RB4, then RB4
re-capsulates it using RB1's nickname as ingress nickname and forwards it
along the tree. When the re-capsulated traffic travels along the branch
where RB1 resides, it will be discarded by the RBridges on this branch due
to the failure of the RPF check. For example, the re-capsulated traffic
will be discarded by RB2 when received at the port on the link RB2-RB4,
since RB2 expect to receive the multcast traffic that has RB1 as ingress
nickname only on the link RB2-RB1.

Contrast to the "Centralized Replication method", I think the "CMT" or the
"Tunneling among edge RBridge" are both feasible.

Thanks,
Hongjun Zhai
-----------------------------------------------------------------------------
Yuhuatai District, Nanjing City, People's Republic of China
Mobile: +086-139-5108-4536
Email: [email-masked]
-----------------------------------------------------------------------------

---

From: Haoweiguo <[email-masked]>
Date: Thu, 20 Feb 2014 08:15:54 +0000

Hi Hongjun,

   Thanks for your careful reading and very good comments! There is really a mistake in the section that
   describing "Centralized Replication" to solve RPF check failure issue!
   The mistake was a result of negligence. The correct "centralized replication" solution should be as follows:

   All ingress RBs send BUM traffic to a centralized node through unicast TRILL
   encapsulation, the centralized node decapsulates the unicast TRILL
   packet. Then the centralized node searches its multicast forwarding
   table to replicates a copy of the BUM traffic to destination RBs
   through TRILL unicast encapsulation.

  Through the centralized replication solution, Multicast replication behavior only occurs on the root node, and only unicast forwarding behavior
   is required between edge RB and centralized RB, so no RPF check function is required on any
   device in TRILL campus through centralized replication solution and
   no RPF check failure issue occurs.

   Centralized node also relies on TRILL based protocol to acquire edge RB
   information and generate multicast forwarding tables.

   thanks
   weiguo

________________________________

发件人: hongjun ZHAI [[email-masked]]
发送时间: 2014年2月19日 21:38
收件人: Haoweiguo; Liyizhou; Donald Eastlake
抄送: [email-masked]
主题: [TRILL] A comment on draft-hao-trill-analysis-active-active-01

Hi authors,

I reviewd the draft and found it gives a good analysis to the solutions for TRILL active-active issue. And a comment on it.

In Section 5.1.2, a "Centralized Replication" method is given to fix the RPFC issue of the Pseudo-nickname(or Virtual RBridge, RBv) solution. According this method, when a member RBridge(say RBi) of a RBv receives BUM traffic, it unicasts the traffic to the root of a distribution tree, say RBn. Then RBn re-encapsulates the traffic with RBi's nickname as
ingress nickname in the new TRILL header and forwards it along a tree. But there is still RFPC issue unresoved in this method.

For exampel, in the following tree topology, where RB1 is the ingress RBridge of RBv, RB4 is the root of the tree.

            +-----+
            | RB4 |
            +-----+
            /    \
           /      \
      +-----+   +-----+
      | RB2 |   | RB3 |
      +-----+   +-----+
        |
     +-----+
     | RB1 |
     +-----+

When receiving a BUM traffic, RB1 unicasts it to RB4, then RB4 re-capsulates it using RB1's nickname as ingress nickname and forwards it along the tree. When the re-capsulated traffic travels along the branch where RB1 resides, it will be discarded by the RBridges on this branch due to the failure of the RPF check. For example, the re-capsulated traffic will be discarded by RB2 when received at the port on the link RB2-RB4, since RB2 expect to receive the multcast traffic that has RB1 as ingress nickname only on the link RB2-RB1.

Contrast to the "Centralized Replication method", I think the "CMT" or the "Tunneling among edge RBridge" are both feasible.

Thanks,
Hongjun Zhai
-----------------------------------------------------------------------------
Yuhuatai District, Nanjing City, People's Republic of China
Mobile: +086-139-5108-4536
Email: [email-masked]<mailto:[email-masked]>
-----------------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 20 Feb 2014 16:46:28 +0800

Hi Weiguo,

>  through TRILL unicast encapsulation. 

Do you mean that you want to employ serial unicast to simulate multicast 
on the root RBridge?

If so, why make the root RBridge other than the ingress edge RBridges to 
do that? 
If we make edge RBridges directly to do that, some bandwith (used by the 
ingress edge RBridge 
to unicast the BUM traffic to the root) can be saved.

Futhermore, if there are many MC-LAGs that are ingressing multicast into 
TRILL campus 
simutaneously, the root RBridge will be sieged by the edge RBridges in 
these MC-LAGs with 
BUM traffic.

And in a TRILL campus with many subscribers of BUM traffic, the 
repulication of the traffic
will make the replicating RBridge (for example the root RBridge) too busy 
to do other things,
such as the ordinary unicast traffic forwarding.

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

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

Haoweiguo <[email-masked]> 
发件人:  "trill" <[email-masked]>
2014-02-20 16:15

收件人
hongjun ZHAI <[email-masked]>, Liyizhou <[email-masked]>, 
Donald Eastlake <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
[trill] 答复: [TRILL] A comment on 
draft-hao-trill-analysis-active-active-01

 Hi Hongjun,
 
   Thanks for your careful reading and very good comments! There is really 
a mistake in the section that 
   describing "Centralized Replication" to solve RPF check failure issue!
   The mistake was a result of negligence. The correct "centralized 
replication" solution should be as follows:

   All ingress RBs send BUM traffic to a centralized node through unicast 
TRILL
 
  Through the centralized replication solution, Multicast replication 
behavior only occurs on the root node, and only unicast forwarding 
behavior
   is required between edge RB and centralized RB, so no RPF check 
function is required on any
   device in TRILL campus through centralized replication solution and
   no RPF check failure issue occurs. 

   thanks
   weiguo

Hi authors,

I reviewd the draft and found it gives a good analysis to the solutions 
for TRILL active-active issue. And a comment on it.

In Section 5.1.2, a "Centralized Replication" method is given to fix the 
RPFC issue of the Pseudo-nickname(or Virtual RBridge, RBv) solution. 
According this method, when a member RBridge(say RBi) of a RBv receives 
BUM traffic, it unicasts the traffic to the root of a distribution tree, 
say RBn. Then RBn re-encapsulates the traffic with RBi's nickname as 
ingress nickname in the new TRILL header and forwards it along a tree. But 
there is still RFPC issue unresoved in this method. 

            +-----+
            | RB4 |
            +-----+
            /    \
           /      \
      +-----+   +-----+
      | RB2 |   | RB3 |
      +-----+   +-----+
        |
     +-----+
     | RB1 |
     +-----+

Thanks, 
Hongjun Zhai
-----------------------------------------------------------------------------
Yuhuatai District, Nanjing City, People's Republic of China
Mobile: +086-139-5108-4536
Email: [email-masked]
-----------------------------------------------------------------------------
_______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: Haoweiguo <[email-masked]>
Date: Fri, 21 Feb 2014 06:44:27 +0000

Hi Hongjun,

Pls see inline reply below.

thanks

weiguo

________________________________
发件人: [email-masked] [[email-masked]]
发送时间: 2014年2月20日 16:46
收件人: Haoweiguo
抄送: Donald Eastlake; hongjun ZHAI; trill; Liyizhou; [email-masked]
主题: [trill] 答复: [TRILL] A comment on draft-hao-trill-analysis-active-active-01

Hi Weiguo,

>  through TRILL unicast encapsulation.

Do you mean that you want to employ serial unicast to simulate multicast on the root RBridge?

If so, why make the root RBridge other than the ingress edge RBridges to do that?
If we make edge RBridges directly to do that, some bandwith (used by the ingress edge RBridge
to unicast the BUM traffic to the root) can be saved.

[weiguo]:If all ingress RB use head-end replication method to replace distribution tree method, more bandwidth between ingress RB and core RB(root RB) will be consumed. In our solution, aggregation RB acts as replication node, so only one copy of BUM traffic is forwarded between ingress RB and centralized node. I think head-end replication mode is suitable for sparse scenario, this solution is suitable for both sparse and dense mode.
In typical 2-Tier spine-leaf network archetecture, this solution can achieve same network bandwidth usage as distribution tree method per TRILL base protocol.
                      ----------
                      | Core   |
                      |--------|

 ------         ------             ------           ------
 |TOR1|      |TOR2|            |TOR3|        |TOR4|
 ------         ------             ------           ------

Futhermore, if there are many MC-LAGs that are ingressing multicast into TRILL campus
simutaneously, the root RBridge will be sieged by the edge RBridges in these MC-LAGs with
BUM traffic.

And in a TRILL campus with many subscribers of BUM traffic, the repulication of the traffic
will make the replicating RBridge (for example the root RBridge) too busy to do other things,
such as the ordinary unicast traffic forwarding.

[weiguo] The strongest forwarding capacity node is normally chosen as centralied replication node, and BUM traffic is not so much as unicast traffic, so i think the centralized node won't become a bottle neck for traffic forwarding.
Even we use distribution tree established per base TRILL protocol,the root node also needs forward all multicast Traffic in TRILL campus.
Thanks,

Hongjun Zhai

Tel: +86 025 52877345

2014-02-20 16:15

收件人
        hongjun ZHAI <[email-masked]>, Liyizhou <[email-masked]>, Donald Eastlake <[email-masked]>
抄送
        "[email-masked]" <[email-masked]>
主题
        [trill] 答复: [TRILL] A comment on draft-hao-trill-analysis-active-active-01

 Hi Hongjun,

   thanks
   weiguo

Hi authors,

           +-----+
           | RB4 |
           +-----+
           /    \
          /      \
     +-----+   +-----+
     | RB2 |   | RB3 |
     +-----+   +-----+
       |
    +-----+
    | RB1 |
    +-----+

Thanks,
Hongjun Zhai
-----------------------------------------------------------------------------_______________________________________________