Subject: Re: [rbridge] Pseudo-node nickname

From: Radia Perlman <[email-masked]>
Date: Sat, 3 Sep 2011 03:12:49 -0700

Sorry Zhai Hongjun for being slow to respond.

I didn't completely understand your post, but let me try to summarize again,
and hopefully I will capture the ideas in your
post (as well as in this whole thread up until now), and if I left anything
out, or misinterpreted anything, you can correct me.

If R1 is DRB giving the pseudonode (let's call it R1.P) nickname X, and then
R2 stops hearing Hellos from R1, so therefore becomes DRB,
naming the pseudonode R2.P, say.
It would be nice if R2 could reuse the pseudonode nickname X, so that
distant RBridges will have correct MAC forwarding tables for the endnodes
attached to the pseudonode.

If R1 is down, then clearly it's OK for R2 to reuse X as the pseudonode
nickname.  But it's possible the link has become partitioned, and R1 is
still alive, and still has some subset of the endnodes attached.

R2 will have trouble recognizing the difference between R1 dead and the link
partitioned, because R1's LSP will not expire immediately.

So...

1) If R1 is indeed down, "pretty soon" R2 will notice that R1 (and the
pseudonode R1.P) are unreachable based on the SPF calculation.

2) I don't think it is distant RBridge R3's job to notice, or take any
action, when there are nickname conflicts.  I think if R1.P and R2.P are
(temporarily) both using
nickname X, that R3 should just calmly compute its forwarding table to the
closest "X", and trust R1 and R2 to work out their conflict.

3) If R1 is indeed down, then there is no problem with R2 using X for
pseudonode R2.P.

4) If the link is partitioned, I don't think there is a big problem with
both R1.P and R2.P using nickname X temporarily.  Indeed, some of the
endnodes will probably be
attached to the partition R1.P, and some to R2.P.

5) So I think a reasonable strategy is for R2 to use the nickname X, and
then after a short time, if R1.P is reachable, then based on priority,
either R1.P or
R2.P will get to keep the nickname X.

6) I don't think there's any need for R2 to try to purge R1's pseudonode
LSP.  It can just start using the nickname.  If R1
is down, then everything will work fine, even though R2's pseudonode LSP has
not timed out, because it will be unreachable
and distant RBridges will calculate towards R2's pseudonode in their
forwarding tables.  If R1 is alive (link partitioned), then
R1 and R2 can fight about who has priority for the nickname, and the one
with higher priority will keep it.

7) I think you were suggesting that R2 start using the pseudonode nickname,
but with a flag in its LSP saying "I am usurping this".
I think that's a good idea.  Without the flag, if R1 were alive, R1 might
just ignore lower priority R2 attempting to use the nickname.
With the flag, it will force R1, if R1 is alive (and the old pseudonode
still exists as a partition) to reissue its pseudonode LSP.
The rule would be "If someone else advertises a pseudonode with the same
nickname as the pseudonode you are DRB for, with
the "I am usurping this nickname" flag, then you MUST reissue your LSP (with
higher sequence number) if you have higher
priority for the nickname.  If you have lower priority for the nickname, you
MUST reissue your LSP (with higher sequence number
of course) with a new nickname.  R2, the usurper, leaves the "I am usurping
this nickname" flag set for some time.  Then several
possibilities:

7a) R2 notices that R1 has become unreachable.  In that case R2 can keep the
nickname, and next time it reissues an LSP (I think
there is no hurry), R2 clears the "usurping" flag.

7b) R2 notices that R1 has issued a new LSP with higher sequence number than
before, still with the same nickname as before,
and with higher priority for the nickname.  In this case R2 MUST relinquish
the nickname and choose a new one.

7c) R2 notices that R1 has issued a new LSP with a different nickname
(because R2 had higher priority for the nickname).  In that case,
like in case 7a), R2 keeps the nickname, and next time it reissues its LSP,
it clears the "usurping" flag.

8) You were also talking about a way of informing distant RBridges to clear
their MAC learning table when a nickname changed.
Perhaps this might be a good thing to signal in ESADI.

I assume already, if AF R4 dies (with nickname N4) and R5 takes over (with
nickname N5), that when distance RBridge R7 attempts to
forward to something in its MAC table that claims to be attached to an
unreachable nickname N4, that R7 would delete that entry
in the MAC table (maybe even delete all of the ones attached to N4).

But you are concerned, I think, with the case where the link partitions into
two pseudonodes, R1.P and R2.P, and there's no way to tell
which endnodes are on which partition.  So I think you are suggesting
warning all the distant RBridges to clear all their MAC
table entries for that pseudonode nickname?  But I think you want R2 to wait
until it is sure it's a partition rather than R1 having
died (because if R2 reuses the nickname and R1 died, then the MAC tables are
still correct).

Radia

2011/8/12 <[email-masked]>

>
> Very good comments.
>
> We should try to avoid purging LSPs owned by another RB, if we can find
> better solution for removing stale entries in TRILL forwarding table in the
> issue of DRB changes and LAN partition.
>
> In TRILL, there are two forwarding tables in data plane for unicast data
> frame. The first is MAC forwarding table, the entry in this table has the
> forming of {Dest_MAC, VLAN-ID, Egress_Nickname}. The second is TRILL ECMP
> table, whose entry has the form of {Egress_nickname, out_port,
> next_hop_mac,...}. The information in the first table is obtained by
> self-learning when decapsulating TRILL data frames. The second table is
> established from the TRILL LSPs. Only if an RBrige is reachable in ECMP
> table, the entry using this RBridge as egress can be added into MAC
> forwarding table. On the other hand, when an RBridge is un-reachable, the
> entry using this RBridge as egress must be removed from MAC forwarding
> table.
>
> So, at the first, in order to aviod the TRILL data frame is discarded at
> the floor hop when LAN is partitioned, we wanted to use the purging
> mechanism to remove the incorrect entries in MAC forwarding table. But, at
> present, another solution is obtained for the issues of DRB changes and LAN
> partition.
>
> A flag for pseudo-node nickname conflicting is introduced in the
> pseudo-node nickname structure. After receiving a pseudo LSP where this flag
> is set in one pseudo-node nickname, the RBridge MUST remove the entries
> associated with this pseudo-node nickname from the ECMP table and MAC table.
> If an RBridge, RB1, detects another RBridge, RB2, is using the same
> pseudo-node nickname as its own in pseudo-node LSPs, RB1 starts a non-cyclic
> waiting timer and updates it pseudo-node LSP where this flag is set to 1 in
> the pseudo-node nickname. After RB2 finds this conflicting, the same thing
> does it. For the tie-breaking of nickname conflicting, the RBridge, for
> example RB2, with higher priority obtains the pseudo-node nickname, and the
> other RBriges, RB1, uses another pseudo nickname. RB2, which obtains the
> pseudo-node nickname, MUST not reset this flag from the pseudo-node nickname
> in its pseudo LSP until the waiting timer expires, which ensures the
> associated entries are removed from other RBridges’ forwarding tables.
>
> It is difficult for an RBridge to distinguish between DRB down and LAN
> partition, but it is easy for an RBridge to find conflict in nickname,
> especially in pseudo-node nickname used by its own. In issue of LAN
> partition, pseudo-node nickname conflict will be detected by DRBs at two
> part of partitioned LAN. After elected as new DRB, the RBridge just reuses
> the pseudo-node nickname already existing on the link in its pseudo-node
> LSPs. Once it detects pseudo-node nickname conflict issue occurs, in which
> another RBridge uses the same pseudo-node nickname in pseudo-node LSPs as
> its own, it will use the above mechanism to eliminate this conflicting.
>
>
>
> Thanks,
> Zhai Hongjun
> """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> 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]
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>
>
>
>
>   *"Les Ginsberg (ginsberg)" <[email-masked]>*
> 发件人:  [email-masked]
>
> 2011-08-06 03:23
>    收件人
> "Radia Perlman" <[email-masked]>, <[email-masked]>
> 抄送
> [email-masked], Erik Nordmark <[email-masked]>,
> [email-masked], [email-masked]
> 主题
> Re: [rbridge] Pseudo-node nickname
>
>
>
>
> There is no need to purge LSPs owned by another RB.
>
> RFC 4971 (Router Capabilities) states in Section 3:
>
> " In order to prevent the use of stale capabilities, a system MUST NOT
>   use a Capability TLV present in an LSP of a system that is not
>   currently reachable via Level-x paths, where "x" is the level (1 or
>   2) in which the sending system advertised the TLV.  "
>
> When DRB changes occur neighbor advertisements to the old DRB will be
> removed from their non-pseudo-node LSPs by systems on the given LAN and
> advertisements to the new pseudo-node will be added. Similarly, the new DRB
> will flood a new pseudo-node LSP with reachability to the neighbors on the
> LAN. So two-way connectivity check to the old DRB will fail and the above
> logic will prevent you from using stale/unreachable nickname information.
>
> In the event the LAN is partitioned (as opposed to the old DRB simply
> failing) again new LSPs (both pseudo-node and non-pseudo-node) will be
> flooded by the nodes on the respective segments and the partitioned two way
> connectivity will be discovered. In that case normal tiebreaking rules
> regarding conflicting nicknames can be applied.
>
> Modifying the update process by trying to preemptively purge LSPs owned by
> another RB is unnecessary, will do no good, and may well cause unnecessary
> and potentially pathological churn if the originating system is still alive.
>
>   Les
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Radia Perlman
> > Sent: Thursday, July 28, 2011 6:59 AM
> > To: [email-masked]
> > Cc: [email-masked]; Erik Nordmark; [email-masked];
> > [email-masked]
> > Subject: Re: [rbridge] Pseudo-node nickname
> >
> > Here's an alternative to purging R1's LSP.
> >
> > Background:  R1 was DRB.  R2 is the new DRB since R2 no longer receives
> > R1's Hellos.
> > R1's LSP will take an unacceptably long time to time out naturally if
> > R1 is indeed dead.
> >
> > Note:  If R2's pseudonode has higher priority for the pseudonode
> > nickname than R1, then
> > if R2 just usurps the nickname, then R2 does not need to purge R1's
> > LSPs.
> >
> > Also, I believe that it will be way more likely that R1 died than that
> > the link partitioned, and
> > even if the link partitioned, either the endnodes attached to R1's
> > partition, or the endnodes
> > attached to R2's partition will have service problems (because remote
> > RBridges will have the
> > wrong nickname for them).
> >
> > So, an alternative to purging R1's LSP is for R2 to usurp the nickname
> > by using a higher
> > priority than R1.  If R1 is dead, then soon nobody will be able to
> > reach that nickname via R1
> > because all of R1's neighbors will declare the link to R1 down.  So it
> > won't be confusing to
> > have R1's unexpired LSP still claiming the nickname if R1 is down.  If
> > R1 is still alive, and
> > the link partitioned, then R1 loses the nickname for the pseudonode and
> > has to choose
> > another one.
> >
> > I don't quite remember how long LSPs hang around when a node goes down.
> > If a node is
> > no longer reachable via the LSP database (because the node is down or
> > the network is
> > partitioned) is there anything that purges the LSP, or does it have to
> > wait an hour or so
> > before it goes away?  If the latter (it hangs around for an hour or
> > so), then I could imagine
> > worrying about having R2 and R1 keep increasing the priority and trying
> > to take the
> > pseudonode nickname back.  So there would have to be rules such as only
> > increasing the
> > priority once, and going back to the old priority once the dead DRB's
> > LSP expires.
> >
> > Though it's possible that it should be legal for R2 to purge R1's LSP
> > provided that R1 is not
> > reachable through the LSP database.  (R2 should not purge R1's LSP if
> > the link had
> > partitioned...only if R1 really is dead).
> >
> > Radia
> >
> >
> >
> > 2011/7/28 [email-masked]
> >
> >
> >
> >                  >> 2011/7/27 <[email-masked]>
> >                  >> The point is that there maybe two cases that R2 loses
> > conncetitvty to R1: one is R1 is died, and the other is the link
> >                  >> partitioning.
> >                  >> If the link is partitioned , R2 Must not purge R1's
> LSP.
> >
> >                  > The problem is, it's hard for R2 to know that R1 is
> still
> > alive, but the link partitioned (that was Erik's
> >                  > original point). In either case (R1 is dead, or the
> link
> > partitioned), R2 will stop hearing Hellos from R1,
> >                  > but R1's LSP will not have timed out. So the
> possibilities are
> >
> >
> >                  ...
> >
> >                  > c) if R2 has higher nickname priority than R1, then R2
> doesn't
> > need to purge R1's LSP. R2 can just start
> >                  > using the pseudonode nickname, and if the link is
> partitioned,
> > R1 will have to acquire a new nickname for
> >                  > it's half of the link. (I think this case is safe and
> > reasonable)
> >
> >
> >                  Yes, it is reasonable and feasible.
> >
> >                  But I think a purging mechanism by prematuring the stale
> DRB's
> > psedo-nickname is required when the old DRB is not in the new DRB's
> > neighbor list.
> >
> >                  Assumed that there are 4 hosts(H1,H2,H3 and H4) and 4
> > RBridges(RB1, RB2, RB3 and RB4, RB1 is DRB) on the initial link E1,
> > which pseudo-nickname is PseNick1. A remote RBridge Rn has learned that
> > the egress to H1,H2,H3 and H4 is PseNick1,and the RBn's shortest path
> > to PseNick1 is through RB1. Now if the link partitions into two halves,
> > RB1,RB2 and H1,H2 on the left half, the others on the right. If not
> > purge the RB1's psedo-nickname from TRILL campus, RBn cannot remove(or
> > update) the entries of H1,..H4 in it's forwarding table(until receiving
> > traffic from H1,..,H4), even if one half link selects another psedo-
> > nicknamee (for examble the right half). Then the traffic to H3 or H4 is
> > discarded at the floor hop. However, if the RB1's psedo-nickname is
> > purged from TRILL, RBn can remove the associated entries from
> > forwarding table, and sends the frames destined to H3 or H4 as unkown
> > unicast frames, which confirms these frames reach H3 or H4.
> >
> >                  After introducing such a purging mechanism, the
> processing of
> > pseudo-nickname for DRB change(including link partition) is as
> > following:
> >
> >                  From neighbor's Hellos or the pseu-nickname stored
> locally, the
> > new DRB can know the pseudo-nickname used before on this link. With
> > this pseudo-nickname as key, it can look up the associated pseudo LSP
> > from its LSDB. If found, the new DRB purges this LSP from the TRILL
> > campus if the older DRB is not in the new DRB's neighbor list. After
> > that, or if not found, the new DRB contends for this nickname by common
> > LSP. If successfully obtains this nickname, it can annouce this
> > nickname in its pseudo LSPs and using it in data plane. Otherwise, it
> > MUST contend for another nickname as pseudo nickname. Before obtaining
> > a pseudo-nickname sucessfully, DRB MUST not use pseudo-nickname in
> > ingressing frames into TRILL campus.
> >
> >                  In brief, the key words are "Purging older DRB's pseudo
> LSP"
> > firstly, "Contending for the pseudo-nickname" secondly, "Announcing the
> > obtained pseudo-nickname in pseudo LSP", and "Using this pseudo-
> > nickname in data plane" finally.
> >
> >
> >
> >
> >                  Thanks,
> >                  Zhai Hongjun
> >
>  """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> > """""
> >                  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 <tel:%2B86-25-52877345>
> >                  Email: [email-masked]
> >
>  """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> > """"""
> >
> >
> >
> >
> >
> > Radia Perlman <[email-masked]>
> >
> > 发件人:  [email-masked]
> >
> > 2011-07-27 23:13
> > 收件人
> > [email-masked]
> > 抄送
> > [email-masked], [email-masked], Erik Nordmark
> > <[email-masked]>
> > 主题
> > Re: [rbridge] Pseudo-node nickname
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >                  2011/7/27 <[email-masked] <mailto:
> [email-masked]> >
> >
> >                  The point is that there maybe two cases  that R2 loses
> > conncetitvty to R1: one is R1 is died, and the other is  the link
> > partitioning.
> >
> >                  If the link is partitioned , R2 Must not purge R1's LSP.
> >
> >                  The problem is, it's hard for R2 to know that R1 is
> still alive,
> > but the link partitioned (that was Erik's original point).  In either
> > case (R1 is dead, or the link partitioned), R2 will stop hearing Hellos
> > from R1, but R1's LSP will not have timed out.  So the possibilities
> > are
> >
> >                  a) wait "awhile", upon taking over as DRB, before
> getting a
> > nickname for the pseudonode.  Note that if R1's LSP hasn't expired, and
> > R1's priority is higher, R2 cannot legally use the nickname for the
> > pseudonode.
> >                  b) if after "awhile" there is no path through current
> LSPs, to
> > R1's LSP, then purge *that* LSP of R1's.  (i.e., only do it once)
> >                  c) if R2 has higher nickname priority than R1, then R2
> doesn't
> > need to purge R1's LSP.  R2 can just start using the pseudonode
> > nickname, and if the link is partitioned, R1 will have to acquire a new
> > nickname for it's half of the link.  (I think this case is safe and
> > reasonable).
> >                  d) don't bother reusing nicknames if the DRB changes,
> but note
> > that AF changes will still be helped by this (the simplest case).
> >
> >                  Perhaps there are other possibilities.  But I think it's
> safe to
> > do c).  The disadvantage of not doing b) is that if R1's pseudonode has
> > higher priority than R2's pseudonode then if R1 dies (more likely than
> > the link partitioning probably), R2 doesn't get to reuse the nickname.
> > But I'm sure people will worry about allowing R2 to purge someone
> > else's LSP, so only doing c)  (allowing R2 to take over the nickname if
> > R2's pseudonode has higher nickname priority), is reasonable.
> >
> >                  Radia
> >
> >
> >
> >                   _______________________________________________
> >                  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
>
>
> --------------------------------------------------------
> 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: [email-masked]
Date: Mon, 5 Sep 2011 20:10:28 +0800

Hi Radia

> I didn't completely understand your post, but let me try to summarize 
again, and hopefully I will capture the ideas in your
> post (as well as in this whole thread up until now), and if I left 
anything out, or misinterpreted anything, you can correct me.

Thank you very much for your patience to try to understand and summrize my 
post.
 
> If R1 is DRB giving the pseudonode (let's call it R1.P) nickname X, and 
then R2 stops hearing Hellos from R1, so therefore becomes DRB,
> It would be nice if R2 could reuse the pseudonode nickname X, so that 
distant RBridges will have correct MAC forwarding tables for the 
> endnodes attached to the pseudonode.
 
> If R1 is down, then clearly it's OK for R2 to reuse X as the pseudonode 
nickname.  But it's possible the link has become partitioned, and 
> R1 is still alive, and still has some subset of the endnodes attached.
 
> R2 will have trouble recognizing the difference between R1 dead and the 
link partitioned, because R1's LSP will not expire immediately.

> 2) I don't think it is distant RBridge R3's job to notice, or take any 
action, when there are nickname conflicts.  I think if R1.P and R2.P 
> are (temporarily) both using
> nickname X, that R3 should just calmly compute its forwarding table to 
the closest "X", and trust R1 and R2 to work out their conflict.

The issue is R3 how to remove the stale MAC entries (using X as egress 
before link partition occurs) because X is still reachable even 
during the period of nickname confliction and after the confliction is 
resolved.

For example, there are 4 hosts, H1, H2, H3 and H4, on the original link 
where RB1 and RB2 are located and a pseudonode nickname X is used. A 
remote RB3 knows from X it can reach the 4 hosts by self-learning. Now if 
the link partitions and H1, H2 and RB1 locate on the left part of 
the partitioned link, and the rests locate on the right part. If RB1 has 
high priority and gets the opportunity to reuse the pesudonode 
nickname X, and RB2 choose another pseudonode nickname Y. Because nickname 
X is still reachable in TRILL control plane for RB3, the stale MAC 
information for H3 and H4 (egress should be Y, no longer X) cannot be 
updated or removed from RB3’s forwarding table at present, which will 
causes the traffic to H3 or H4 is discarded at the floor hop.

So, I think it is safe that RB3 can remove all the MAC entries with 
conflicting nickname X as egress when it finds this confliction. Although, 
the correct MAC entries for H1 and H2 are also removed during the nickname 
confliction, these entries will be built by self-learning soon. 
Furthermore,the traffic to H1 and H2 can be multicasted to them before 
these entries are learned. 

> 4) If the link is partitioned, I don't think there is a big problem with 
both R1.P and R2.P using nickname X temporarily.  Indeed, some of 
> the endnodes will probably be attached to the partition R1.P, and some 
to R2.P. 

But it will cause some MAC entries becoming stale in remote RBridge's, 
RB3's, forwaring table and cannot be corrected before receiving data frame 

from R1 or R2. These stale entries will cause the traffic to be losed at 
the floor hop. One example is given in the above description.
 
> either R1.P or R2.P will get to keep the nickname X.

Yes, I agree on it. 
In addition, we should find a method to help remote RBrdiges to remove the 
stale MAC entries from their forwarding table. For example, the nickname 
conflicting flag method proposed in my past post.
 
> is down, then everything will work fine, even though R2's pseudonode LSP 
has not timed out, because it will be unreachable

Yes, I don't think it is a good way for RB2 to purge RB1's pseudonode LSP, 
which will cause pathological churn if R1 is still alive.
So the method of conflicting flag for nickname is proposed.
 
> 7) I think you were suggesting that R2 start using the pseudonode 
nickname, but with a flag in its LSP saying "I am usurping this".
> I think that's a good idea.  Without the flag, if R1 were alive, R1 
might just ignore lower priority R2 attempting to use the nickname.
> the "I am usurping this nickname" flag, then you MUST reissue your LSP 
(with higher sequence number) if you have higher
> priority for the nickname.  If you have lower priority for the nickname, 
you MUST reissue your LSP (with higher sequence number
> of course) with a new nickname.  R2, the usurper, leaves the "I am 
usurping this nickname" flag set for some time.  Then several
> possibilities:

Thanks for your summarization. It is right but not so accurate.

My method is that the new DRB, R2, just to reuse the pseudonode nickname X 
and announce this nickname in its pseudo-node LSP. After finding 
confliction of this nickname, it will try to solve this confliction with 
its competitor. The discription is as following:

1) If R1 is indeed down and the link is not partitioned, it’s OK for R2 
to use X as its pseudonode nickname because no confliction of this 
nickname is found.

2) If R1 is still alive (but in other part of the partitioned link), R1 
will detect this pseudonode nickname confliction after received R2’s 
R2.P where the pseudonode nickname X is contained. Then R1 updates its 
R1.P LSP (with higher sequence number) where the pseudonode nickname X is 
associated with a nickname conflicting flag set 1(Note: only after the 
nickname confliction is found, this flag is set 1) saying "I am using a 
conflicted nickname", and starts a waiting timer.

After R2 finds this nickname confliction by receiving RB1’s updated R1.P 
LSP, it will update its R2.P LSP as does R1.

Just like your suggestion, using the priority as tie-breaker, the RBridge 
(R2) with low priority MUST relinquish this nickname and choose a new one, 
for example, nickname Y.

For a remote RBridge, RB3, if it notices this flag being set 1 in a 
pseudonode nickname X, it should remove all the MAC entries using X as 
egress to avoid the caused stale entries by this confliction from its 
forwarding table. But at current there is no mechanism to help RB3 to 
remove the above stale MAC entries. With the help of this conflicting flag 
in pseudonode nickname X, RB3 can remove all the MAC entries with X as 
egress during the period of confliction of pseudonode nickname X. After 
the waiting timer expires, this conflicting flag is clear from nickname X 
by the nickname owner, and then RB3 can use it in establishment of new MAC 
entries by self-learning.
 
> 7a) R2 notices that R1 has become unreachable.  In that case R2 can keep 
the nickname, and next time it reissues an LSP (I think
 
> 7b) R2 notices that R1 has issued a new LSP with higher sequence number 
than before, still with the same nickname as before,
> and with higher priority for the nickname.  In this case R2 MUST 
relinquish the nickname and choose a new one.
 
> like in case 7a), R2 keeps the nickname, and next time it reissues its 
LSP, it clears the "usurping" flag.
 
See the discription of conflicting flag as above.

> 8) You were also talking about a way of informing distant RBridges to 
clear their MAC learning table when a nickname changed.
> Perhaps this might be a good thing to signal in ESADI.

Yes, if ESADI is employed by all the ingress/egress RBridges, the stale 
MAC entries can be removed accurately from remote RBridge's forwarding 
table (without removal of correct MAC entries). But ESADI is only optional 
for ingress and egress, is not running on all of these RBridges. So it 
should not entirely depend on ESADI to inform distant RBridges to clear 
their MAC learning table when a nickname changed.
 
> I assume already, if AF R4 dies (with nickname N4) and R5 takes over 
(with nickname N5), that when distance RBridge R7 attempts to
> in the MAC table (maybe even delete all of the ones attached to N4).

I think it is feasible for distant RBridges R7 to delete all of the MAC 
enries with N4 as egress, because there is a AF flag in the R4's LSP. When 
the AF flag is clear from R4's LSP, R7 should delete all the associated 
MAC enries from its forwarding table. 

So I think the nickname conflicting flag is able to have the same use as 
AF flag to some extent. 
 
> But you are concerned, I think, with the case where the link partitions 
into two pseudonodes, R1.P and R2.P, and there's no way to tell
> table entries for that pseudonode nickname?

Yes, the nickname conficting flag is really used to warn all the distant 
RBridges to clear all the associated MAC entries. Furthermore, this flag 
is also used to notify the competitor of this nickname that confliction of 
this nickname is found by another RBridge.

> But I think you want R2 to wait until it is sure it's a partition rather 
than R1 having
> died (because if R2 reuses the nickname and R1 died, then the MAC tables 
are still correct).

Yes, only when R2 is sure that it's a partition (not R1 having died), it 
sets the nickname conflicting flag in the pseudonode nickname in its 
pseodonode LSP.

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

2011-09-03 18:12

收件人
[email-masked]
抄送

I didn't completely understand your post, but let me try to summarize 
again, and hopefully I will capture the ideas in your
post (as well as in this whole thread up until now), and if I left 
anything out, or misinterpreted anything, you can correct me.
 
If R1 is DRB giving the pseudonode (let's call it R1.P) nickname X, and 
then R2 stops hearing Hellos from R1, so therefore becomes DRB,
naming the pseudonode R2.P, say.
It would be nice if R2 could reuse the pseudonode nickname X, so that 
distant RBridges will have correct MAC forwarding tables for the endnodes
attached to the pseudonode.

R2 will have trouble recognizing the difference between R1 dead and the 
link partitioned, because R1's LSP will not expire immediately.
 
So...

 

 
6) I don't think there's any need for R2 to try to purge R1's pseudonode 
LSP.  It can just start using the nickname.  If R1
is down, then everything will work fine, even though R2's pseudonode LSP 
has not timed out, because it will be unreachable
and distant RBridges will calculate towards R2's pseudonode in their 
forwarding tables.  If R1 is alive (link partitioned), then
R1 and R2 can fight about who has priority for the nickname, and the one 
with higher priority will keep it.
 
7) I think you were suggesting that R2 start using the pseudonode 
nickname, but with a flag in its LSP saying "I am usurping this".
I think that's a good idea.  Without the flag, if R1 were alive, R1 might 
just ignore lower priority R2 attempting to use the nickname.
With the flag, it will force R1, if R1 is alive (and the old pseudonode 
still exists as a partition) to reissue its pseudonode LSP.
The rule would be "If someone else advertises a pseudonode with the same 
nickname as the pseudonode you are DRB for, with
the "I am usurping this nickname" flag, then you MUST reissue your LSP 
(with higher sequence number) if you have higher
priority for the nickname.  If you have lower priority for the nickname, 
you MUST reissue your LSP (with higher sequence number
of course) with a new nickname.  R2, the usurper, leaves the "I am 
usurping this nickname" flag set for some time.  Then several
possibilities:
 
7a) R2 notices that R1 has become unreachable.  In that case R2 can keep 
the nickname, and next time it reissues an LSP (I think
there is no hurry), R2 clears the "usurping" flag.
 
7b) R2 notices that R1 has issued a new LSP with higher sequence number 
than before, still with the same nickname as before,
and with higher priority for the nickname.  In this case R2 MUST 
relinquish the nickname and choose a new one.
 
7c) R2 notices that R1 has issued a new LSP with a different nickname 
(because R2 had higher priority for the nickname).  In that case,
like in case 7a), R2 keeps the nickname, and next time it reissues its 
LSP, it clears the "usurping" flag.

8) You were also talking about a way of informing distant RBridges to 
clear their MAC learning table when a nickname changed.
Perhaps this might be a good thing to signal in ESADI.

But you are concerned, I think, with the case where the link partitions 
into two pseudonodes, R1.P and R2.P, and there's no way to tell
which endnodes are on which partition.  So I think you are suggesting 
warning all the distant RBridges to clear all their MAC
table entries for that pseudonode nickname?  But I think you want R2 to 
wait until it is sure it's a partition rather than R1 having
died (because if R2 reuses the nickname and R1 died, then the MAC tables 
are still correct).
 
Radia

Very good comments. 
  
We should try to avoid purging LSPs owned by another RB, if we can find 
better solution for removing stale entries in TRILL forwarding table in 
the issue of DRB changes and LAN partition. 

So, at the first, in order to aviod the TRILL data frame is discarded at 
the floor hop when LAN is partitioned, we wanted to use the purging 
mechanism to remove the incorrect entries in MAC forwarding table. But, at 
present, another solution is obtained for the issues of DRB changes and 
LAN partition. 

A flag for pseudo-node nickname conflicting is introduced in the 
pseudo-node nickname structure. After receiving a pseudo LSP where this 
flag is set in one pseudo-node nickname, the RBridge MUST remove the 
entries associated with this pseudo-node nickname from the ECMP table and 
MAC table. If an RBridge, RB1, detects another RBridge, RB2, is using the 
same pseudo-node nickname as its own in pseudo-node LSPs, RB1 starts a 
non-cyclic waiting timer and updates it pseudo-node LSP where this flag is 
set to 1 in the pseudo-node nickname. After RB2 finds this conflicting, 
the same thing does it. For the tie-breaking of nickname conflicting, the 
RBridge, for example RB2, with higher priority obtains the pseudo-node 
nickname, and the other RBriges, RB1, uses another pseudo nickname. RB2, 
which obtains the pseudo-node nickname, MUST not reset this flag from the 
pseudo-node nickname in its pseudo LSP until the waiting timer expires, 
which ensures the associated entries are removed from other RBridges’ 
forwarding tables. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

"Les Ginsberg (ginsberg)" <[email-masked]> 
发件人:  [email-masked] 
2011-08-06 03:23 

收件人

When DRB changes occur neighbor advertisements to the old DRB will be 
removed from their non-pseudo-node LSPs by systems on the given LAN and 
advertisements to the new pseudo-node will be added. Similarly, the new 
DRB will flood a new pseudo-node LSP with reachability to the neighbors on 
the LAN. So two-way connectivity check to the old DRB will fail and the 
above logic will prevent you from using stale/unreachable nickname 
information.

In the event the LAN is partitioned (as opposed to the old DRB simply 
failing) again new LSPs (both pseudo-node and non-pseudo-node) will be 
flooded by the nodes on the respective segments and the partitioned two 
way connectivity will be discovered. In that case normal tiebreaking rules 
regarding conflicting nicknames can be applied.

Modifying the update process by trying to preemptively purge LSPs owned by 
another RB is unnecessary, will do no good, and may well cause unnecessary 
and potentially pathological churn if the originating system is still 
alive.

  Les

LSP.
still
link
possibilities are
> 
> 
>                  ...
> 
>                  > c) if R2 has higher nickname priority than R1, then 
R2 doesn't
partitioned,
>                  But I think a purging mechanism by prematuring the 
stale DRB's
processing of
locally, the
LSP"
Corporation
P.R.China,
[email-masked]> >
LSP.
still alive,
getting a
LSPs, to
doesn't
but note
>                  Perhaps there are other possibilities.  But I think 
it's safe to
contained in
confidential and
ZTE Anti-

--------------------------------------------------------
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: Ayan Banerjee <[email-masked]>
Date: Mon, 05 Sep 2011 21:40:45 -0700

Please see in-line.

Thanks,
Ayan

On 9/5/11 5:10 AM, "[email-masked]" <[email-masked]>
wrote:

> The issue is R3 how to remove the stale MAC entries (using X as egress before
> link partition occurs) because X is still reachable even
> For example, there are 4 hosts, H1, H2, H3 and H4, on the original link where
> RB1 and RB2 are located and a pseudonode nickname X is used. A
> remote RB3 knows from X it can reach the 4 hosts by self-learning. Now if the
> link partitions and H1, H2 and RB1 locate on the left part of
> the partitioned link, and the rests locate on the right part. If RB1 has high
> priority and gets the opportunity to reuse the pesudonode
> nickname X, and RB2 choose another pseudonode nickname Y. Because nickname X
> is still reachable in TRILL control plane for RB3, the stale MAC
> information for H3 and H4 (egress should be Y, no longer X) cannot be updated
> or removed from RB3’s forwarding table at present, which will
> conflicting nickname X as egress when it finds this confliction. Although, the
> correct MAC entries for H1 and H2 are also removed during the nickname
> Furthermore,the traffic to H1 and H2 can be multicasted to them before these
> entries are learned.
> 
> [Ayan] Don’t you think that incrementing the AFLC on the Interested Vlan TLV
> will aid in this purpose?
> 
> Thanks,
> Ayan
> 
> 
>  
>> > the endnodes will probably be attached to the partition R1.P, and some to
>> R2.P. 
> 
> But it will cause some MAC entries becoming stale in remote RBridge's, RB3's,
> forwaring table and cannot be corrected before receiving data frame
> from R1 or R2. These stale entries will cause the traffic to be losed at the
> floor hop. One example is given in the above description.
>  
> My method is that the new DRB, R2, just to reuse the pseudonode nickname X and
> announce this nickname in its pseudo-node LSP. After finding
> confliction of this nickname, it will try to solve this confliction with its
> competitor. The discription is as following:
> 
> 1) If R1 is indeed down and the link is not partitioned, it’s OK for R2 to use
> X as its pseudonode nickname because no confliction of this nickname is found.
> 
> 2) If R1 is still alive (but in other part of the partitioned link), R1 will
> detect this pseudonode nickname confliction after received R2’s
> R2.P where the pseudonode nickname X is contained. Then R1 updates its R1.P
> LSP (with higher sequence number) where the pseudonode nickname X is
> After R2 finds this nickname confliction by receiving RB1’s updated R1.P LSP,
> it will update its R2.P LSP as does R1.
> 
> Just like your suggestion, using the priority as tie-breaker, the RBridge (R2)
> with low priority MUST relinquish this nickname and choose a new one, for
> example, nickname Y.
> 
> For a remote RBridge, RB3, if it notices this flag being set 1 in a pseudonode
> nickname X, it should remove all the MAC entries using X as egress to avoid
> the caused stale entries by this confliction from its forwarding table. But at
> current there is no mechanism to help RB3 to remove the above stale MAC
> entries. With the help of this conflicting flag in pseudonode nickname X, RB3
> can remove all the MAC entries with X as egress during the period of
> confliction of pseudonode nickname X. After the waiting timer expires, this
> conflicting flag is clear from nickname X by the nickname owner, and then RB3
> can use it in establishment of new MAC entries by self-learning.
>  
> Yes, if ESADI is employed by all the ingress/egress RBridges, the stale MAC
> entries can be removed accurately from remote RBridge's forwarding table
> (without removal of correct MAC entries). But ESADI is only optional for
> ingress and egress, is not running on all of these RBridges. So it should not
> entirely depend on ESADI to inform distant RBridges to clear their MAC
> learning table when a nickname changed.
>  
> I think it is feasible for distant RBridges R7 to delete all of the MAC enries
> with N4 as egress, because there is a AF flag in the R4's LSP. When the AF
> flag is clear from R4's LSP, R7 should delete all the associated MAC enries
> from its forwarding table.
> 
> So I think the nickname conflicting flag is able to have the same use as AF
> flag to some extent.
>  
> RBridges to clear all the associated MAC entries. Furthermore, this flag is
> also used to notify the competitor of this nickname that confliction of this
> nickname is found by another RBridge.
> 
> Yes, only when R2 is sure that it's a partition (not R1 having died), it sets
> the nickname conflicting flag in the pseudonode nickname in its pseodonode
> LSP. 
> 
>> > Radia 
> 
> 
> 
> Thanks,
> Zhai Hongjun
> 发件人:  [email-masked] 2011-09-03 18:12
> 收件人 
> [email-masked]
> 抄送 
> It would be nice if R2 could reuse the pseudonode nickname X, so that distant
> RBridges will have correct MAC forwarding tables for the endnodes
> 2) I don't think it is distant RBridge R3's job to notice, or take any action,
> when there are nickname conflicts.  I think if R1.P and R2.P are (temporarily)
> both using 
> 4) If the link is partitioned, I don't think there is a big problem with both
> R1.P and R2.P using nickname X temporarily.  Indeed, some of the endnodes will
> probably be 
> 5) So I think a reasonable strategy is for R2 to use the nickname X, and then
> after a short time, if R1.P is reachable, then based on priority, either R1.P
> or 
> 6) I don't think there's any need for R2 to try to purge R1's pseudonode LSP.
> It can just start using the nickname.  If R1
> R1 and R2 can fight about who has priority for the nickname, and the one with
> higher priority will keep it.
>  
> I think that's a good idea.  Without the flag, if R1 were alive, R1 might just
> ignore lower priority R2 attempting to use the nickname.
> With the flag, it will force R1, if R1 is alive (and the old pseudonode still
> exists as a partition) to reissue its pseudonode LSP.
> 7c) R2 notices that R1 has issued a new LSP with a different nickname (because
> R2 had higher priority for the nickname).  In that case,
> like in case 7a), R2 keeps the nickname, and next time it reissues its LSP, it
> clears the "usurping" flag.
>  
>  
> which endnodes are on which partition.  So I think you are suggesting warning
> all the distant RBridges to clear all their MAC
> 2011/8/12 <[email-masked] <mailto:[email-masked]> >
> 
> Very good comments.
>   
> We should try to avoid purging LSPs owned by another RB, if we can find better
> solution for removing stale entries in TRILL forwarding table in the issue of
> DRB changes and LAN partition.
> 
> established from the TRILL LSPs. Only if an RBrige is reachable in ECMP table,
> the entry using this RBridge as egress can be added into MAC forwarding table.
> On the other hand, when an RBridge is un-reachable, the entry using this
> RBridge as egress must be removed from MAC forwarding table.
> 
> So, at the first, in order to aviod the TRILL data frame is discarded at the
> floor hop when LAN is partitioned, we wanted to use the purging mechanism to
> remove the incorrect entries in MAC forwarding table. But, at present, another
> solution is obtained for the issues of DRB changes and LAN partition.
> 
> A flag for pseudo-node nickname conflicting is introduced in the pseudo-node
> nickname structure. After receiving a pseudo LSP where this flag is set in one
> pseudo-node nickname, the RBridge MUST remove the entries associated with this
> pseudo-node nickname from the ECMP table and MAC table. If an RBridge, RB1,
> detects another RBridge, RB2, is using the same pseudo-node nickname as its
> own in pseudo-node LSPs, RB1 starts a non-cyclic waiting timer and updates it
> pseudo-node LSP where this flag is set to 1 in the pseudo-node nickname. After
> RB2 finds this conflicting, the same thing does it. For the tie-breaking of
> nickname conflicting, the RBridge, for example RB2, with higher priority
> obtains the pseudo-node nickname, and the other RBriges, RB1, uses another
> pseudo nickname. RB2, which obtains the pseudo-node nickname, MUST not reset
> this flag from the pseudo-node nickname in its pseudo LSP until the waiting
> timer expires, which ensures the associated entries are removed from other
> RBridges’ forwarding tables.
> 
> especially in pseudo-node nickname used by its own. In issue of LAN partition,
> pseudo-node nickname conflict will be detected by DRBs at two part of
> partitioned LAN. After elected as new DRB, the RBridge just reuses the
> pseudo-node nickname already existing on the link in its pseudo-node LSPs.
> Once it detects pseudo-node nickname conflict issue occurs, in which another
> RBridge uses the same pseudo-node nickname in pseudo-node LSPs as its own, it
> will use the above mechanism to eliminate this conflicting.
> 
> 
> 
> Thanks,
> Zhai Hongjun
> Email: [email-masked] <mailto:[email-masked]>
> "Les Ginsberg (ginsberg)" <[email-masked] <mailto:[email-masked]> >
> 发件人:  [email-masked] <mailto:[email-masked]>
> 2011-08-06 03:23 
> 收件人 
> "Radia Perlman" <[email-masked] <mailto:[email-masked]> >,
> <[email-masked] <mailto:[email-masked]> >
> 抄送 
> [email-masked] <mailto:[email-masked]> , Erik Nordmark
> <[email-masked] <mailto:[email-masked]> >, [email-masked]
> <mailto:[email-masked]> , [email-masked]
> <mailto:[email-masked]>
> 主题 
> When DRB changes occur neighbor advertisements to the old DRB will be removed
> from their non-pseudo-node LSPs by systems on the given LAN and advertisements
> to the new pseudo-node will be added. Similarly, the new DRB will flood a new
> pseudo-node LSP with reachability to the neighbors on the LAN. So two-way
> connectivity check to the old DRB will fail and the above logic will prevent
> you from using stale/unreachable nickname information.
> 
> In the event the LAN is partitioned (as opposed to the old DRB simply failing)
> again new LSPs (both pseudo-node and non-pseudo-node) will be flooded by the
> nodes on the respective segments and the partitioned two way connectivity will
> be discovered. In that case normal tiebreaking rules regarding conflicting
> nicknames can be applied.
> 
> another RB is unnecessary, will do no good, and may well cause unnecessary and
> potentially pathological churn if the originating system is still alive.
> 
>   Les
> 
> 
>> > From: [email-masked] <mailto:[email-masked]>
>> [mailto:[email-masked] <mailto:[email-masked]> ] On
>> > Behalf Of Radia Perlman
>> > To: [email-masked] <mailto:[email-masked]>
>> > Cc: [email-masked] <mailto:[email-masked]> ; Erik Nordmark;
>> [email-masked] <mailto:[email-masked]> ;
>> > [email-masked] <mailto:[email-masked]>
>> > 2011/7/28 [email-masked] <mailto:[email-masked]>
>> > 
>> > 
>> > 
>>>> >                  >> 2011/7/27 <[email-masked]
>>>> <mailto:[email-masked]> >
LSP.
still
link
possibilities are
doesn't
partitioned,
>> >                  After introducing such a purging mechanism, the processing
>> of
>> <tel:%2B86-25-52877345>
>> <mailto:[email-masked]>
>> >               
>> > Radia Perlman <[email-masked] <mailto:[email-masked]> >
>> > 
>> > 发件人:  [email-masked] <mailto:[email-masked]>
>> > 
>> > 2011-07-27 23:13
>> > 收件人
>> > [email-masked] <mailto:[email-masked]>
>> > 抄送
>> > [email-masked] <mailto:[email-masked]> , [email-masked]
>> <mailto:[email-masked]> , Erik Nordmark
>> > <[email-masked] <mailto:[email-masked]> >
>> > 主题
>> >                  2011/7/27 <[email-masked]
>> <mailto:[email-masked]> <mailto:[email-masked]
>> <mailto:[email-masked]> > >
>> > 
>> >                  The problem is, it's hard for R2 to know that R1 is still
>> alive,
>> >                  a) wait "awhile", upon taking over as DRB, before getting
a
>> >                  d) don't bother reusing nicknames if the DRB changes, but
>> note
>> >                  [email-masked] <mailto:[email-masked]> 
>> <http://mailman.postel.org/mailman/listinfo/rbridge> 
>> > 
>> > 
>> > 
>> >                  ZTE Information Security Notice: The information contained 
>> in
>> >                  This message has been scanned for viruses and Spam by ZTE 
>> Anti-
>> > Spam system.
>> > 
> 
> 
> [email-masked] <mailto:[email-masked]> 
> <http://mailman.postel.org/mailman/listinfo/rbridge> 
> 
> 
> confidential. Recipients named above are obligated to maintain secrecy and are 
> not permitted to disclose the contents of this communication to others.
> 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.
> confidential. Recipients named above are obligated to maintain secrecy and are 
> not permitted to disclose the contents of this communication to others.
> 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.

---

From: [email-masked]
Date: Tue, 6 Sep 2011 19:12:21 +0800

Please see in-line.

Thanks,
Zhai Hongjun

Ayan Banerjee <[email-masked]> 
发件人:  [email-masked]
2011-09-06 12:40

收件人
<[email-masked]>, Radia Perlman <[email-masked]>
抄送
[email-masked], Erik Nordmark <[email-masked]>, 
[email-masked], [email-masked]
主题
Re: [rbridge] Pseudo-node nickname

>> Thank you very much for your patience to try to understand and summrize 
my post. 
 
>>> If R1 is DRB giving the pseudonode (let's call it R1.P) nickname X, 
and then R2 stops hearing Hellos from R1, so therefore becomes DRB, 
 
>>> If R1 is down, then clearly it's OK for R2 to reuse X as the 
pseudonode nickname.  But it's possible the link has become partitioned, 
and 

>>> R2 will have trouble recognizing the difference between R1 dead and 
the link partitioned, because R1's LSP will not expire immediately. 

resolved. 

>> remote RB3 knows from X it can reach the 4 hosts by self-learning. Now 
if the link partitions and H1, H2 and RB1 locate on the left part of 
>> the partitioned link, and the rests locate on the right part. If RB1 
has high priority and gets the opportunity to reuse the pesudonode 
>> nickname X, and RB2 choose another pseudonode nickname Y. Because 
nickname X is still reachable in TRILL control plane for RB3, the stale 
MAC 

the correct MAC entries 
>> for H1 and H2 are also removed during the nickname confliction, these 
entries will be built by self-learning soon. Furthermore,the traffic to H1 
and H2 can be 
> > multicasted to them before these entries are learned. 

       > [Ayan] Don’t you think that incrementing the AFLC on the 
Interested Vlan TLV will aid in this purpose?

                [Zhai Hongjun]  Thanks for your good comment.  I think 
your proposed method of  incrementing the AFLC  can work for this purpose. 

 AF for VLAN-x is designated by DRB on a link, so the DRB can know all the 
VLANs on its link.  When a DRB finds the confliction of pseudonode 
nickname and has to choose a new one as pseudonode nickname for its low 
priority, it will increase the AFLC on the Interested VLAN TLV, where the 
contained nickname is the conflicting pseudonode nickname,  for all the 
VLANs on the link it standing for. After receiving such a TLV, distant 
RBridges can adjust the remaining time for each associated MAC entry to 
"Forward Delay",which is 15 seconds in default. 

Although, in the period of "Foward Delay", the traffic loss at the floor 
hop still exists, I think it can be accepted for that short time.  During 
the confliction of pseudonode nickname, the DRB with high priority dosen't 
need to flood this TLV in its LSP, because it will win in contending for 
this nickname at last. I think this rule is useful to handle the 
associated MAC entries in distant RBrides more accurate.

Furthmore, if pseudonode nickname function is enabled on a link, only the 
DRB is permitted to use pseudonode nickname in this TLV, and other 
RBridges on this link are prohibited to use this nickname in this TLV, 
which can help  to remain the MAC entries in distant RBridges unchanged as 
possible as it can. When the DRB finds that some VLANs are lost on its 
link, it should  increase the AFLC for the lost VLANs in this TLV and 
floods it in TRILL campus, which can help remote RBridges to handle the 
associated MAC entries.

Thanks,
Zhai Hongjun

>>> 4) If the link is partitioned, I don't think there is a big problem 
with both R1.P and R2.P using nickname X temporarily.  Indeed, some of 
to R2.P. 

>> from R1 or R2. These stale entries will cause the traffic to be losed 
at the floor hop. One example is given in the above description. 
 
>>> 5) So I think a reasonable strategy is for R2 to use the nickname X, 
and then after a short time, if R1.P is reachable, then based on priority, 

>> Yes, I agree on it. 
>> In addition, we should find a method to help remote RBrdiges to remove 
the stale MAC entries from their forwarding table. For example, the 
nickname 
 
>>> 6) I don't think there's any need for R2 to try to purge R1's 
pseudonode LSP.  It can just start using the nickname.  If R1 
>>> is down, then everything will work fine, even though R2's pseudonode 
LSP has not timed out, because it will be unreachable 
>>> R1 and R2 can fight about who has priority for the nickname, and the 
one with higher priority will keep it. 

>> Yes, I don't think it is a good way for RB2 to purge RB1's pseudonode 
LSP, which will cause pathological churn if R1 is still alive. 
 
>>> With the flag, it will force R1, if R1 is alive (and the old 
pseudonode still exists as a partition) to reissue its pseudonode LSP. 
>>> The rule would be "If someone else advertises a pseudonode with the 
same nickname as the pseudonode you are DRB for, with 
>>> priority for the nickname.  If you have lower priority for the 
nickname, you MUST reissue your LSP (with higher sequence number 

>> My method is that the new DRB, R2, just to reuse the pseudonode 
nickname X and announce this nickname in its pseudo-node LSP. After 
finding 
>> confliction of this nickname, it will try to solve this confliction 
with its competitor. The discription is as following: 

>> 1) If R1 is indeed down and the link is not partitioned, it’s OK for 
R2 to use X as its pseudonode nickname because no confliction of this 
nickname is found. 

conflicted nickname", 
>> and starts a waiting timer. 

> > After R2 finds this nickname confliction by receiving RB1’s updated 
R1.P LSP, it will update its R2.P LSP as does R1. 

>> Just like your suggestion, using the priority as tie-breaker, the 
RBridge (R2) with low priority MUST relinquish this nickname and choose a 
new one, for example, 
>> nickname Y. 

egress to avoid the 
>> caused stale entries by this confliction from its forwarding table. But 
at current there is no mechanism to help RB3 to remove the above stale MAC 
entries. 
>> With the help of this conflicting flag in pseudonode nickname X, RB3 
confliction of 
>> pseudonode nickname X. After the waiting timer expires, this 
conflicting flag is clear from nickname X by the nickname owner, and then 
RB3 can use it in 
>> establishment of new MAC entries by self-learning. 
 
>>> 7a) R2 notices that R1 has become unreachable.  In that case R2 can 
keep the nickname, and next time it reissues an LSP (I think 
 
>>> 7b) R2 notices that R1 has issued a new LSP with higher sequence 
number than before, still with the same nickname as before, 

table (without 
>> removal of correct MAC entries). But ESADI is only optional for ingress 
and egress, is not running on all of these RBridges. So it should not 
entirely depend on 
>> ESADI to inform distant RBridges to clear their MAC learning table when 
a nickname changed. 

the AF flag is clear 
>> from R4's LSP, R7 should delete all the associated MAC enries from its 
forwarding table. 

>> So I think the nickname conflicting flag is able to have the same use 
as AF flag to some extent. 
 
>>> But you are concerned, I think, with the case where the link 
partitions into two pseudonodes, R1.P and R2.P, and there's no way to tell 

>> Yes, the nickname conficting flag is really used to warn all the 
distant RBridges to clear all the associated MAC entries. Furthermore, 
this flag is also used to notify
>> the competitor of this nickname that confliction of this nickname is 
found by another RBridge. 

>>> But I think you want R2 to wait until it is sure it's a partition 
rather than R1 having 
>>> died (because if R2 reuses the nickname and R1 died, then the MAC 
tables are still correct). 

>> Yes, only when R2 is sure that it's a partition (not R1 having died), 
it sets the nickname conflicting flag in the pseudonode nickname in its 
pseodonode LSP. 

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

So... 

 

Radia 

Very good comments. 

Thanks,
Zhai Hongjun

Zhai Hongjun

"Les Ginsberg (ginsberg)" <[email-masked] <mailto:[email-masked]> 
发件人:  [email-masked] <mailto:[email-masked]> 
2011-08-06 03:23 
收件人 
"Radia Perlman" <[email-masked] <mailto:[email-masked]> >, 
<[email-masked] <mailto:[email-masked]> > 
抄送 
[email-masked] <mailto:[email-masked]> , Erik Nordmark <
[email-masked] <mailto:[email-masked]> >, [email-masked] <
mailto:[email-masked]> , [email-masked] <
mailto:[email-masked]> 
主题 
Re: [rbridge] Pseudo-node nickname 

  Les

> From: [email-masked] <mailto:[email-masked]> 
[mailto:[email-masked] <mailto:[email-masked]> ] 
On
>                  >> 2011/7/27 <[email-masked] <
mailto:[email-masked]> >
LSP.
still
link
possibilities are
R2 doesn't
partitioned,
stale DRB's
processing of
locally, the
LSP"
Corporation
P.R.China,
<tel:%2B86-25-52877345>
>                  2011/7/27 <[email-masked] <
mailto:[email-masked]> <mailto:[email-masked] <
mailto:[email-masked]> > >
LSP.
still alive,
getting a
LSPs, to
doesn't
but note
it's safe to
>                  http://mailman.postel.org/mailman/listinfo/rbridge <
http://mailman.postel.org/mailman/listinfo/rbridge> 
contained in
confidential and
ZTE Anti-

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