[rbridge] Pseudo-node nickname
Ayan Banerjee
ayabaner at cisco.com
Mon Sep 5 21:40:45 PDT 2011
Please see in-line.
Thanks,
Ayan
On 9/5/11 5:10 AM, "zhai.hongjun at zte.com.cn" <zhai.hongjun at zte.com.cn>
wrote:
>
> 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,
>> > 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...
>
>> > 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.
>
> [Ayan] Don¡¯t you think that incrementing the AFLC on the Interested Vlan TLV
> will aid in this purpose?
>
> Thanks,
> Ayan
>
>
>
>> > 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.
>
>> > 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.
>
> 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.
>
>> > 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.
>
> 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.
>> > 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:
>
> 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
>> > 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.
>
> 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
>> > 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).
>
> 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
>> > 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?
>
> 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.
>
>> > Radia
>
>
>
> 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: zhai.hongjun at zte.com.cn
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>
>
>
>
> Radia Perlman <radiaperlman at gmail.com>
> ·¢¼þÈË: rbridge-bounces at postel.org 2011-09-03 18:12
> ÊÕ¼þÈË
> zhai.hongjun at zte.com.cn
> ³ËÍ
> rbridge at postel.org, Erik Nordmark <nordmark at acm.org>,
> rbridge-bounces at postel.org, hu.fangwei at zte.com.cn
> Ö÷Ìâ
> Re: [rbridge] Pseudo-node nickname
>
>
>
>
> 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 <zhai.hongjun at zte.com.cn <mailto:zhai.hongjun at zte.com.cn> >
>
> 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 <tel:%2B86-25-52877345>
> Email: zhai.hongjun at zte.com.cn <mailto:zhai.hongjun at zte.com.cn>
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>
>
>
> "Les Ginsberg (ginsberg)" <ginsberg at cisco.com <mailto:ginsberg at cisco.com> >
> ·¢¼þÈË: rbridge-bounces at postel.org <mailto:rbridge-bounces at postel.org>
> 2011-08-06 03:23
> ÊÕ¼þÈË
> "Radia Perlman" <radiaperlman at gmail.com <mailto:radiaperlman at gmail.com> >,
> <zhai.hongjun at zte.com.cn <mailto:zhai.hongjun at zte.com.cn> >
> ³ËÍ
> rbridge at postel.org <mailto:rbridge at postel.org> , Erik Nordmark
> <nordmark at acm.org <mailto:nordmark at acm.org> >, rbridge-bounces at postel.org
> <mailto:rbridge-bounces at postel.org> , hu.fangwei at zte.com.cn
> <mailto:hu.fangwei at zte.com.cn>
> Ö÷Ìâ
> 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: rbridge-bounces at postel.org <mailto:rbridge-bounces at postel.org>
>> [mailto:rbridge-bounces at postel.org <mailto:rbridge-bounces at postel.org> ] On
>> > Behalf Of Radia Perlman
>> > Sent: Thursday, July 28, 2011 6:59 AM
>> > To: zhai.hongjun at zte.com.cn <mailto:zhai.hongjun at zte.com.cn>
>> > Cc: rbridge at postel.org <mailto:rbridge at postel.org> ; Erik Nordmark;
>> rbridge-bounces at postel.org <mailto:rbridge-bounces at postel.org> ;
>> > hu.fangwei at zte.com.cn <mailto:hu.fangwei at zte.com.cn>
>> > 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 zhai.hongjun at zte.com.cn <mailto:zhai.hongjun at zte.com.cn>
>> >
>> >
>> >
>>>> > >> 2011/7/27 <hu.fangwei at zte.com.cn
>>>> <mailto:hu.fangwei at zte.com.cn> >
>>>> > >> 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>
>> <tel:%2B86-25-52877345>
>> > Email: zhai.hongjun at zte.com.cn
>> <mailto:zhai.hongjun at zte.com.cn>
>> >
>> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>> > """"""
>> >
>> >
>> >
>> >
>> >
>> > Radia Perlman <radiaperlman at gmail.com <mailto:radiaperlman at gmail.com> >
>> >
>> > ·¢¼þÈË: rbridge-bounces at postel.org <mailto:rbridge-bounces at postel.org>
>> >
>> > 2011-07-27 23:13
>> > ÊÕ¼þÈË
>> > hu.fangwei at zte.com.cn <mailto:hu.fangwei at zte.com.cn>
>> > ³ËÍ
>> > rbridge at postel.org <mailto:rbridge at postel.org> , zhai.hongjun at zte.com.cn
>> <mailto:zhai.hongjun at zte.com.cn> , Erik Nordmark
>> > <nordmark at acm.org <mailto:nordmark at acm.org> >
>> > Ö÷Ìâ
>> > Re: [rbridge] Pseudo-node nickname
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > 2011/7/27 <hu.fangwei at zte.com.cn
>> <mailto:hu.fangwei at zte.com.cn> <mailto:hu.fangwei at zte.com.cn
>> <mailto:hu.fangwei at zte.com.cn> > >
>> >
>> > 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
>> > rbridge at postel.org <mailto:rbridge at postel.org>
>> > http://mailman.postel.org/mailman/listinfo/rbridge
>> <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
> rbridge at postel.org <mailto:rbridge at postel.org>
> http://mailman.postel.org/mailman/listinfo/rbridge
> <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
> rbridge at postel.org
> 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
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110905/22e9f39d/attachment-0001.html
More information about the rbridge
mailing list