Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Thu, 5 Jan 2012 18:11:55 -0800

Dear All

We have published draft-tissa-trill-cmt-00.txt, in this document we
present a flexible framework to associate child RBridges to different
parent RBRidges for RPF purpose.

Active-active forwarding at the TRILL edge is a very important feature.
Representation of the active-active sub system with a single virtual
RBRidge is a common practice to achieve load balancing and to avoid MAC
flip flop. However, use of virtual RBridge lead to RPF failures. In this
document we provide a solution to address the RPF failures. Please
review and share comments.

ID can be found in URL:
http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt

Summary:

Filename:   draft-tissa-trill-cmt

Revision:   00

Title:            Coordinated Multicast Trees (CMT)for TRILL

Creation date:    2012-01-05

WG ID:            Individual Submission

Number of pages: 14

Abstract:

   TRILL facilitates loop free connectivity to non TRILL legacy

   networks via choice of an Appointed Forwarder for set of VLANs.

   Appointed Forwarder provides VLAN level load sharing with active-

   standby model. Mission critical operations such as High Performance

   Data Centers require active-active load sharing model. Active-Active

   load sharing model can be accomplished by representing any given non

   TRILL legacy network with a single virtual RBridge. Virtual

   representation of the non-TRILL legacy network with a single RBridge

   poses serious challenges in multi-destination RPF calculations. This

   document presents the required enhancements to build Coordinated

   Multicast Trees (CMT) within the TRILL campus. CMT provides

   flexibility to RBridges to select desired path of association to a

   given distribution tree.

Thanks

Tissa

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: [email-masked]
Date: Fri, 13 Jan 2012 11:58:44 +0800

Hi Tissa,

I have read your draft-tissa-trill-cmt-00.txt with great interests.  In 
this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member 
RBdige of a virtual RBridge group much flexibity in describing the virtual 
RBridge nickname and  specifying the path of association to specific 
distribution tree(S).  However, this new TLV causes some backward 
compatibilty problems between pre Affinity sub-TLV RBridges and new 
RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL 
network,the RPF check for virtual Rbridge will fail on this RBridge.

Is the Affinity Sub-TLV necessary for a member RBridge to announce the 
virtual Rbridge nickname and  the specific distribution trees? Maybe it is 
not.

In a given vritual group, each  member Rbridge can advertise a specific 
pseudonode-LSP to annouce the virtual RBridge nickname and the trees 
assigned to it.The nickname and the assigned trees are contained in  the 
given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP 
represents a special virtual link, on which there is only one RBridge, 
i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge 
is assigned different tree(s), RPF check information for the virtual 
Rbrigde in different trees can be correctly calculated on all the Rbridges 
in TRILL network, then the member RBridge can safely use the virtual 
Rbridge nickname to do the necessary TRILL-encapsultion on  received 
native frames.

Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is 
removed, while the similar flexibilty of Affinity sub-TLV remains.

Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: [email-masked]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

"Tissa Senevirathne (tsenevir)" <[email-masked]> 
发件人:  [email-masked]
2012-01-06 10:11

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

主题
[rbridge] Coordinated Multicast Trees to solve RPF issues on active-active 
edge and more

Dear All

document we provide a solution to address the RPF failures. Please review 
and share comments.
 
ID can be found in URL: 
 
Summary:

Abstract:

Thanks
Tissa_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Thu, 12 Jan 2012 20:21:26 -0800

Hi Hongjun

I am not quite clear with the way you are proposing to use assigned nicknames in the pseudonode LSP.

Can you please us the diagram below and explain how your proposal will be used. 

CE means in the following diagram is an 802.1D device that is attached to RB1 and RB2 through Pt-Pt links and treated as a port channel from CE stand point.

                                   RBx

                                     |

                           Trill Campus

               |                                              |

    +----------+                                   +------------+

    |  RB1     |                                  |  RB2       |

    +----------+                                  + ------------+

          \                                                  /

           \                                               /

            \                                            /

              ----------               -----------

                      >   |             |  <  Port channel (LAG)

                           |             |

                    +--------------------+

                   |    CE                    |

                   +---------------------+

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, January 12, 2012 7:59 PM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked]; [email-masked]
Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more

Hi Tissa, 

I have read your draft-tissa-trill-cmt-00.txt with great interests.  In this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member RBdige of a virtual RBridge group much flexibity in describing the virtual RBridge nickname and  specifying the path of association to specific distribution tree(S).  However, this new TLV causes some backward compatibilty problems between pre Affinity sub-TLV RBridges and new RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL network,the RPF check for virtual Rbridge will fail on this RBridge.

Is the Affinity Sub-TLV necessary for a member RBridge to announce the virtual Rbridge nickname and  the specific distribution trees? Maybe it is not. 

In a given vritual group, each  member Rbridge can advertise a specific pseudonode-LSP to annouce the virtual RBridge nickname and the trees assigned to it.The nickname and the assigned trees are contained in  the given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP represents a special virtual link, on which there is only one RBridge, i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge is assigned different tree(s), RPF check information for the virtual Rbrigde in different trees can be correctly calculated on all the Rbridges in TRILL network, then the member RBridge can safely use the virtual Rbridge nickname to do the necessary TRILL-encapsultion on  received native frames. 

Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is removed, while the similar flexibilty of Affinity sub-TLV remains. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-01-06 10:11 

收件人

<[email-masked]> 

抄送

主题

[rbridge] Coordinated Multicast Trees to solve RPF issues on        active-active edge and more

Dear All 
  
We have published draft-tissa-trill-cmt-00.txt, in this document we present a flexible framework to associate child RBridges to different parent RBRidges for RPF purpose. 
  
Active-active forwarding at the TRILL edge is a very important feature. Representation of the active-active sub system with a single virtual RBRidge is a common practice to achieve load balancing and to avoid MAC flip flop. However, use of virtual RBridge lead to RPF failures. In this document we provide a solution to address the RPF failures. Please review and share comments. 
  
ID can be found in URL: http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt <http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt>  
  
Summary: 

Abstract: 

Thanks

---

From: [email-masked]
Date: Fri, 13 Jan 2012 13:05:29 +0800

Hi Tissa，

In the diagram you given, assume 4 distribution trees are acturally 
calculated in TRILL campus, i.e., T1 through T4.  T1 and T2 are assigned 
to RB1, T3 and T4 are assigned to RB2.

Even if RB1 can not see  RB2 by hellos, (I think that) RB1 can generate a 
pseudonode LSP, Pseu-LSP-RB1,  to announce the virtual RBridge (RBv) 
nickname and the trees assigned to it, i.e, T1 and T2.  In this pseudonode 
LSP,  RB1 is the only one neighbor (or RB1 and the virtual RBridge RBv are 
the only two neigbors)  of this pseudonode.  After receiving this 
pseudonode LSP,  RBx can  know the path to  pseudonode RBv through RB1 on 
T1 or T2, shown in the following diagram.

                                  RBx
                                     |
                           Trill Campus
               |                                              |
          \ 
          /  \ 
        /RBv \ 
       ---------
                scheme of T1 or T2

RB1 uses Nickname Sub-TLV and Trees Sub-TLV (instead of the Affinity 
sub-TLV) in Pseu-LSP-RB1, to contains the RBv's nickname and the assigned 
trees T1 and T2.

RB2 also annouce similar informtion in its pseudonode LSP, then RBx can 
know the path to RBv through RB2 on T3 and T4.

                                  RBx
                                     |
                           Trill Campus
               |                                              |
                           |             |
                    +--------------------+
                   |    CE                    |
                   +---------------------+

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

2012-01-13 12:21

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more

Hi Hongjun
 
I am not quite clear with the way you are proposing to use assigned 
nicknames in the pseudonode LSP.
 
Can you please us the diagram below and explain how your proposal will be 
used. 
 
CE means in the following diagram is an 802.1D device that is attached to 
RB1 and RB2 through Pt-Pt links and treated as a port channel from CE 
stand point.
 
                                   RBx
                                     |
                           Trill Campus
               |                                              |
                           |             |
                    +--------------------+
                   |    CE                    |
                   +---------------------+

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, January 12, 2012 7:59 PM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked]; [email-masked]
Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more

Hi Tissa, 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

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

主题

Dear All 

  
ID can be found in URL: 
  
Summary: 

Abstract: 

Thanks 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Janardhanan Pathangi Narasimhan <[email-masked]>
Date: Fri, 13 Jan 2012 19:18:56 +0530

Hi Hongjun,

I think your proposal is that form a tree rooted at RB1 and another tree rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,  and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are forcing the affinity of RB1 or RB2 to RBV by placing the root on the RBridges themselves. Is that correct?

Yes, this mechanism would work, but would not scale up. For e.g. in the network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, RB3-RB4 providing RBV2, and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 trees (10 pairs of RB). This will not scale, while with affinity TLV irrespective of number of such RB pairs which are providing such services we would need only two trees.

Thanks
Jana

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 13, 2012 10:35 AM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked]; [email-masked]
Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more

Hi Tissa，

In the diagram you given, assume 4 distribution trees are acturally calculated in TRILL campus, i.e., T1 through T4.  T1 and T2 are assigned to RB1, T3 and T4 are assigned to RB2.

Even if RB1 can not see  RB2 by hellos, (I think that) RB1 can generate a pseudonode LSP, Pseu-LSP-RB1,  to announce the virtual RBridge (RBv) nickname and the trees assigned to it, i.e, T1 and T2.  In this pseudonode LSP,  RB1 is the only one neighbor (or RB1 and the virtual RBridge RBv are the only two neigbors)  of this pseudonode.  After receiving this pseudonode LSP,  RBx can  know the path to  pseudonode RBv through RB1 on T1 or T2, shown in the following diagram.

                                  RBx
                                     |
                           Trill Campus
               |                                              |

RB1 uses Nickname Sub-TLV and Trees Sub-TLV (instead of the Affinity sub-TLV) in Pseu-LSP-RB1, to contains the RBv's nickname and the assigned trees T1 and T2.

RB2 also annouce similar informtion in its pseudonode LSP, then RBx can know the path to RBv through RB2 on T3 and T4.

                                  RBx
                                     |
                           Trill Campus
               |                                              |
                           |             |
                    +--------------------+
                   |    CE                    |
                   +---------------------+

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-01-13 12:21

收件人

抄送

主题

RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more

Hi Hongjun

                                   RBx
                                     |
                           Trill Campus
               |                                              |
                           |             |
                    +--------------------+
                   |    CE                    |
                   +---------------------+

Hi Tissa,

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-01-06 10:11

收件人

<[email-masked]>

抄送

主题

Dear All

ID can be found in URL: http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt

Summary:

Abstract:

Thanks

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 13 Jan 2012 11:03:36 -0800

I agree with Jana.
Scaling will be a major factor if we go the other route. Affinity TLV provides much better option while providing the same service with two trees.

Sam

Sent from my iPad

---

From: Jon Hudson <[email-masked]>
Date: Fri, 13 Jan 2012 11:44:42 -0800

Great explanation Jana!

Scaling is the challenge.

---

From: [email-masked]
Date: Sat, 14 Jan 2012 12:16:44 +0800

Hi Jana, Jon and Tissa,

> I think your proposal is that form a tree rooted at RB1 and another tree 
rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link, 
> and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you 
are forcing the affinity of RB1 or RB2 to RBV by placing the root on the 
RBridges themselves. 
> Is that correct? 

No, It didn't mean that the trees must rooted at RB1, RB2, respectively. 
It has no any needs of where the roots of these trees are. These trees are 
ordinary trees calculated by all RBridges in TRILL campus wide.

For example, there are 4 actually-calculated trees in TRILL campus, T1 
through T4. T1 roots at RBi, T2 roots at RBj, T3 roots at RBm and T4 roots 
at RBn. If T1 and T2 are assigned to member RBridge RB1, and the rest 
trees to RB2. The method used to assign trees to a member RBridge is the 
same as given in Section 5.1 in draft CMT. 

In the below topology, Since RB1 knows it is a member RBridge of Rbridge 
Group RBv1 and that T1/T2 are assigned to it, RB1 can originate a 
pseudonode LSP(even if it has not seen any neighbors in RBv by hellos) and 
advertize it in TRILL campus. This pseudonode LSP contains a Nickname 
sub-TLV where nickname of RBv1 is carried, and a Trees sub_TLV where the 
wanted-to-using tress(i.e., T1 and T2) are carried, as well as a neighbor 
TLV where RB1 is the only neighbor contained in this pseudonode LSP.

After receiving this  psuedonode LSP, another RBridge, e.g., RBx,  knows 
the paths to RBv through RB1 on T1 and T2. Then RPF information for RBv1 
can be calculated correctly by RBx on these two trees.
                                 RBx 
                                     | 
                           Trill Campus 
               |                                              | 
    +----------+                                   +------------+ 
    |  RB1     |                                  |  RB2       | 
    +----------+                                  + ------------+ 
          \                                                  / 
           \                                               / 
            \                                            / 
              ----------               ----------- 
                           |             | 
                    +--------------------+ 
                   |    CE                    | 
                   +---------------------+ 

Besides RBv1, If RB1joins another Rbridge Group RBv2, and T2/T3 are 
assigned to RB1, RB1 can originates another pseudonode LSP, where nickname 
of RBv2 and T2/T3 are carried in Nickname sub-TLV and Trees sub-TLV, 
respectively. After receiving this LSP, RBx can knows path to RBv2 through 
RB1 on T2 and T3. RPF check information can also calculated correctly by 
RBx on thes two trees.

Similar things RB2 can do, and RPF check information can be calculated 
correctly by RBx on the assigned trees
 
> Yes, this mechanism would work, but would not scale up. For e.g. in the 
network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, 
RB3-RB4 providing RBV2, 
> and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 
and so on are present, we will have to minimum build 20 trees (10 pairs of 
RB). 
> This will not scale, while with affinity TLV irrespective of number of 
such RB pairs which are providing such services we would need only two 
trees.

No, It does not require much more trees to build if using pseudonode LSP, 
instead of affinity TLV,  to notify other RBridges the affinity of RBv via 
RB1. It just needs to originate much more pseudonode LSPs if an Rbridge 
joins more than one RBridge Group.

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

Janardhanan Pathangi Narasimhan <[email-masked]> 
发件人:  [email-masked]
2012-01-13 21:48

收件人
"[email-masked]" <[email-masked]>, "Tissa Senevirathne 
(tsenevir)" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more

Hi Hongjun,
 
I think your proposal is that form a tree rooted at RB1 and another tree 
rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,  and 
similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are 
forcing the affinity of RB1 or RB2 to RBV by placing the root on the 
RBridges themselves. Is that correct? 
 
Yes, this mechanism would work, but would not scale up. For e.g. in the 
network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, 
RB3-RB4 providing RBV2, and so on, then to ensure that RB1-RBV1, RB2-RBV1, 
RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 
trees (10 pairs of RB). This will not scale, while with affinity TLV 
irrespective of number of such RB pairs which are providing such services 
we would need only two trees.
 
Thanks
Jana

From: [email-masked] [mailto:[email-masked]] On 
Behalf Of [email-masked]
Sent: Friday, January 13, 2012 10:35 AM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked]; [email-masked]
Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more

Hi Tissa， 

                                  RBx 
                                     | 
                           Trill Campus 
               |                                              | 

                                  RBx 
                                     | 
                           Trill Campus 
               |                                              | 
                           |             | 
                    +--------------------+ 
                   |    CE                    | 
                   +---------------------+ 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Hi Hongjun 

  
  
                                   RBx 
                                     | 
                           Trill Campus 
               |                                              | 
                           |             | 
                    +--------------------+ 
                   |    CE                    | 
                   +---------------------+ 

Hi Tissa, 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

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

主题

Dear All 

 
ID can be found in URL: 
 
Summary: 

Abstract: 

Thanks 

system._______________________________________________

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Sat, 14 Jan 2012 07:04:34 -0800

Hi Hongjun

Technically speaking what you are proposing is similar to Affinity TLV approach. With the difference of using Pseudonode LSP instead of the Affinity TLV .

Main issue with PSN-LSP approach is the scale, Let me explain that in bit more details.

Affinity TLV is a single sub-TLV announced by each of the members of active-active pair or pairs.

Similarly PSN-LSP is also announced by each of the members of active-active pair or pairs.

However, PSN-LSP is a fully contained LSP that contain  multiple TLV s that needed to fully form a PSN.

This will increase the size of the LSP-DB of the campus and introduce X more additional TLVs.

There can be many  active-active pair/pairs in the network, and with this approach we have so many more additional LSP in the network.

As we know size of LSP-DB is a major scaling issue and always want to keep it as small as possible, where possible.

Lets also look at why PSN-LSP approach being proposed. It is to solve a possible backward compatibility issue.

TRILL still in infancy and there are not many TRILL networks.  So the backward compatibility is not a wide spread issue. Also affinity draft has backward compatibility mode.

What we should look at is having a solution that help us to scale better as TRILL become widely deployed in Large data-centers/Enterprises where such active-active edge is widely used.

With PSN-LSP approach I think we are unnecessarily injecting additional LSP and TLVs and making it more complicated and less scalable when we can solve with a single sub-TLV. Also Affinity TLV draft discuss backward compatibility approach, in the event there older Rbridges.

Thanks

Tissa

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 13, 2012 8:17 PM
To: Janardhanan Pathangi Narasimhan
Cc: [email-masked]; [email-masked]; Tissa Senevirathne (tsenevir)
Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more

Hi Jana, Jon and Tissa, 

> I think your proposal is that form a tree rooted at RB1 and another tree rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,   
> and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are forcing the affinity of RB1 or RB2 to RBV by placing the root on the RBridges themselves. 
> Is that correct? 

No, It didn't mean that the trees must rooted at RB1, RB2, respectively.  It has no any needs of where the roots of these trees are. These trees are ordinary trees calculated by all RBridges in TRILL campus wide. 

For example, there are 4 actually-calculated trees in TRILL campus, T1 through T4. T1 roots at RBi, T2 roots at RBj, T3 roots at RBm and T4 roots at RBn. If T1 and T2 are assigned to member RBridge RB1, and the rest trees to RB2. The method used to assign trees to a member RBridge is the same as given in Section 5.1 in draft CMT. 

In the below topology, Since RB1 knows it is a member RBridge of Rbridge Group RBv1 and that T1/T2 are assigned to it, RB1 can originate a pseudonode LSP(even if it has not seen any neighbors in RBv by hellos) and advertize it in TRILL campus. This pseudonode LSP contains a Nickname sub-TLV where nickname of RBv1 is carried, and a Trees sub_TLV where the wanted-to-using tress(i.e., T1 and T2) are carried, as well as a neighbor TLV where RB1 is the only neighbor contained in this pseudonode LSP. 

After receiving this  psuedonode LSP, another RBridge, e.g., RBx,  knows the paths to RBv through RB1 on T1 and T2. Then RPF information for RBv1 can be calculated correctly by RBx on these two trees. 
                                 RBx 
                                    | 
                          Trill Campus 
              |                                              | 
   +----------+                                   +------------+ 
   |  RB1     |                                  |  RB2       | 
   +----------+                                  + ------------+ 
         \                                                  / 
          \                                               / 
           \                                            / 
             ----------               ----------- 
                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 

Besides RBv1, If RB1joins another Rbridge Group RBv2, and T2/T3 are assigned to RB1, RB1 can originates another pseudonode LSP, where nickname of RBv2 and T2/T3 are carried in Nickname sub-TLV and Trees sub-TLV, respectively. After receiving this LSP, RBx can knows path to RBv2 through RB1 on T2 and T3. RPF check information can also calculated correctly by RBx on thes two trees. 

Similar things RB2 can do, and RPF check information can be calculated correctly by RBx on the assigned trees 
  
> Yes, this mechanism would work, but would not scale up. For e.g. in the network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, RB3-RB4 providing RBV2, 
> and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 trees (10 pairs of RB). 
> This will not scale, while with affinity TLV irrespective of number of such RB pairs which are providing such services we would need only two trees. 

No, It does not require much more trees to build if using pseudonode LSP, instead of affinity TLV,  to notify other RBridges the affinity of RBv via RB1. It just needs to originate much more pseudonode LSPs if an Rbridge joins more than one RBridge Group. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-01-13 21:48 

收件人

"[email-masked]" <[email-masked]>, "Tissa Senevirathne        (tsenevir)" <[email-masked]> 

抄送

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 

主题

Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more

Hi Hongjun, 

  
Thanks 
Jana 

Hi Tissa， 

                                 RBx 
                                    | 
                          Trill Campus 
              |                                              | 

                                 RBx 
                                    | 
                          Trill Campus 
              |                                              | 
                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-01-13 12:21 

收件人

抄送

主题

  

Hi Hongjun 

 
 
                                  RBx 
                                    | 
                          Trill Campus 
              |                                              | 
                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 

Hi Tissa, 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-01-06 10:11 

收件人

<[email-masked]> 

抄送

主题

  

Dear All 

Summary: 

Abstract: 

Thanks 

This message has been scanned for viruses and Spam by ZTE Anti-Spam system._______________________________________________

---

From: Jon Hudson <[email-masked]>
Date: Sat, 14 Jan 2012 20:10:19 -0800

Just to add a few data points

As of now only Cisco and Brocade have been shipping a "TRILL based" product 

By late 2011 numbers of units in production networks
Cisco >500
Brocade >300 

So with growth let's assume 1000-1200 total.

However neither Brocade or Ciscos solution is pure openTRILL. Both have work to do on that front.

As I understand it Force10 & Extreme will ship soon but have not yet.

In addition the affinity-TLV does not require a hardware change for anyone (that I am aware of). And since those ~1000 today will need some software updates anyway to become compliant, backwards comparability is essentially a non issue for the affinity TLV.

If the PSN-LSP solution increased scalability, or added functionality then it (or anything else that does) deserves careful consideration.  

PSN-LSP seems to only gain something that isn't hyper critical in this case and adds scaling concerns.

I often have to alleviate concerns that TRILL contains scaling issues in its use of IS-IS, I don't wish to add fuel to that fire. 

My 0x2 bits

---

From: [email-masked]
Date: Mon, 16 Jan 2012 10:17:55 +0800

Hi Tissa:

Thanks for your detailed explanation. 

> Technically speaking what you are proposing is similar to Affinity TLV 
approach. With the difference of using Pseudonode LSP instead of the 
Affinity TLV .
Yes, they are similar in technically speaking. PSN-LSP approach is 
proposed to solve a backward compatibility issue.

> As we know size of LSP-DB is a major scaling issue and always want to 
keep it as small as possible, where possible.
If size of LSP-DB is really a major scaling issue, I think we should speed 
up the standardiztion of Multi-level TRILL, a draft proposed by Radia 
Perlman. I think that Multi-level TRILL is the best way to reduce the size 
of LSP-DB in a big TRILL campus.

> TRILL still in infancy and there are not many TRILL networks.  So the 
backward compatibility is not a wide spread issue. 
> Also affinity draft has backward compatibility mode.
OK, At present(TRILL still in infancy), if backward compatibility issue 
caused by Affinity TLV can be accepted, Affinity TLV is OK. I just gave my 
suggestion to solve the back compatibility issue caused by affinity TLV. 
I'm glad to see any one good technology to be standardized.

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

2012-01-14 23:04

收件人
<[email-masked]>, "Janardhanan Pathangi Narasimhan" 
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more

Hi Hongjun
 
Technically speaking what you are proposing is similar to Affinity TLV 
approach. With the difference of using Pseudonode LSP instead of the 
Affinity TLV .
 
Main issue with PSN-LSP approach is the scale, Let me explain that in bit 
more details.
 
Affinity TLV is a single sub-TLV announced by each of the members of 
active-active pair or pairs.
 
Similarly PSN-LSP is also announced by each of the members of 
active-active pair or pairs.
 
However, PSN-LSP is a fully contained LSP that contain  multiple TLV s 
that needed to fully form a PSN.
 
This will increase the size of the LSP-DB of the campus and introduce X 
more additional TLVs.
 
There can be many  active-active pair/pairs in the network, and with this 
approach we have so many more additional LSP in the network.
 
As we know size of LSP-DB is a major scaling issue and always want to keep 
it as small as possible, where possible.
 
Lets also look at why PSN-LSP approach being proposed. It is to solve a 
possible backward compatibility issue.
 
TRILL still in infancy and there are not many TRILL networks.  So the 
backward compatibility is not a wide spread issue. Also affinity draft has 
backward compatibility mode.
 
What we should look at is having a solution that help us to scale better 
as TRILL become widely deployed in Large data-centers/Enterprises where 
such active-active edge is widely used.
 
With PSN-LSP approach I think we are unnecessarily injecting additional 
LSP and TLVs and making it more complicated and less scalable when we can 
solve with a single sub-TLV. Also Affinity TLV draft discuss backward 
compatibility approach, in the event there older Rbridges.
 
Thanks
Tissa
 
Cc: [email-masked]; [email-masked]; Tissa Senevirathne 
(tsenevir)

Hi Jana, Jon and Tissa, 

                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 

  

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Hi Hongjun, 

  
Thanks 
Jana 

Hi Tissa， 

                                 RBx 
                                    | 
                          Trill Campus 
              |                                              | 

                                 RBx 
                                    | 
                          Trill Campus 
              |                                              | 
                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Hi Hongjun 

 
 
                                  RBx 
                                    | 
                          Trill Campus 
              |                                              | 
                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 

Hi Tissa, 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

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

主题

Dear All 

ID can be found in URL: 

Summary: 

Abstract: 

Thanks