[rbridge] Pseudo-node nickname
Radia Perlman
radiaperlman at gmail.com
Sat Sep 3 03:12:49 PDT 2011
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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110903/7b5cea14/attachment-0001.html
More information about the rbridge
mailing list