[rbridge] Pseudo-node nickname
zhai.hongjun@zte.com.cn
zhai.hongjun at zte.com.cn
Mon Sep 5 05:10:28 PDT 2011
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.
> 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>
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: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
"Les Ginsberg (ginsberg)" <ginsberg at cisco.com>
·¢¼þÈË: rbridge-bounces at postel.org
2011-08-06 03:23
ÊÕ¼þÈË
"Radia Perlman" <radiaperlman at gmail.com>, <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
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] On
> Behalf Of Radia Perlman
> Sent: Thursday, July 28, 2011 6:59 AM
> To: zhai.hongjun at zte.com.cn
> Cc: rbridge at postel.org; Erik Nordmark; rbridge-bounces at postel.org;
> 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
>
>
>
> >> 2011/7/27 <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>
> Email: zhai.hongjun at zte.com.cn
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> """"""
>
>
>
>
>
> Radia Perlman <radiaperlman at gmail.com>
>
> ·¢¼þÈË: rbridge-bounces at postel.org
>
> 2011-07-27 23:13
> ÊÕ¼þÈË
> hu.fangwei at zte.com.cn
> ³ËÍ
> rbridge at postel.org, zhai.hongjun at zte.com.cn, Erik Nordmark
> <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> >
>
> 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
> 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
--------------------------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110905/93988036/attachment-0001.html
More information about the rbridge
mailing list