[rbridge] Pseudo-node nickname
zhai.hongjun@zte.com.cn
zhai.hongjun at zte.com.cn
Tue Sep 6 04:12:21 PDT 2011
Please see in-line.
Thanks,
Zhai Hongjun
Ayan Banerjee <ayabaner at cisco.com>
·¢¼þÈË: rbridge-bounces at postel.org
2011-09-06 12:40
ÊÕ¼þÈË
<zhai.hongjun at zte.com.cn>, Radia Perlman <radiaperlman at gmail.com>
³ËÍ
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
> 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?
[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
> 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
_______________________________________________
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/20110906/6411bfb4/attachment-0001.html
More information about the rbridge
mailing list