Subject: Re: [rbridge] Pseudo-node nickname

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 5 Aug 2011 12:23:50 -0700

There is no need to purge LSPs owned by another RB.
 
RFC 4971 (Router Capabilities) states in Section 3:

" In order to prevent the use of stale capabilities, a system MUST NOT
   use a Capability TLV present in an LSP of a system that is not
   currently reachable via Level-x paths, where "x" is the level (1 or
   2) in which the sending system advertised the TLV.  "

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

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

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

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Radia Perlman
> Sent: Thursday, July 28, 2011 6:59 AM
> To: [email-masked]
> Cc: [email-masked]; Erik Nordmark; [email-masked];
> [email-masked]
> Subject: Re: [rbridge] Pseudo-node nickname
> 
> Here's an alternative to purging R1's LSP.
> 
> Background:  R1 was DRB.  R2 is the new DRB since R2 no longer receives
> R1's Hellos.
> R1's LSP will take an unacceptably long time to time out naturally if
> R1 is indeed dead.
> 
> Note:  If R2's pseudonode has higher priority for the pseudonode
> nickname than R1, then
> if R2 just usurps the nickname, then R2 does not need to purge R1's
> LSPs.
> 
> Also, I believe that it will be way more likely that R1 died than that
> the link partitioned, and
> even if the link partitioned, either the endnodes attached to R1's
> partition, or the endnodes
> attached to R2's partition will have service problems (because remote
> RBridges will have the
> wrong nickname for them).
> 
> So, an alternative to purging R1's LSP is for R2 to usurp the nickname
> by using a higher
> priority than R1.  If R1 is dead, then soon nobody will be able to
> reach that nickname via R1
> because all of R1's neighbors will declare the link to R1 down.  So it
> won't be confusing to
> have R1's unexpired LSP still claiming the nickname if R1 is down.  If
> R1 is still alive, and
> the link partitioned, then R1 loses the nickname for the pseudonode and
> has to choose
> another one.
> 
> I don't quite remember how long LSPs hang around when a node goes down.
> If a node is
> no longer reachable via the LSP database (because the node is down or
> the network is
> partitioned) is there anything that purges the LSP, or does it have to
> wait an hour or so
> before it goes away?  If the latter (it hangs around for an hour or
> so), then I could imagine
> worrying about having R2 and R1 keep increasing the priority and trying
> to take the
> pseudonode nickname back.  So there would have to be rules such as only
> increasing the
> priority once, and going back to the old priority once the dead DRB's
> LSP expires.
> 
> Though it's possible that it should be legal for R2 to purge R1's LSP
> provided that R1 is not
> reachable through the LSP database.  (R2 should not purge R1's LSP if
> the link had
> partitioned...only if R1 really is dead).
> 
> Radia
> 
> 
> 
> 2011/7/28 [email-masked]
> 
> 
> 
> 	>> 2011/7/27 <[email-masked]>
> 	>> The point is that there maybe two cases that R2 loses
> conncetitvty to R1: one is R1 is died, and the other is the link
> 	>> partitioning.
> 	>> If the link is partitioned , R2 Must not purge R1's LSP.
> 
> 	> The problem is, it's hard for R2 to know that R1 is still
> alive, but the link partitioned (that was Erik's
> 	> original point). In either case (R1 is dead, or the link
> partitioned), R2 will stop hearing Hellos from R1,
> 	> but R1's LSP will not have timed out. So the possibilities are
> 
> 
> 	...
> 
> 	> c) if R2 has higher nickname priority than R1, then R2 doesn't
> need to purge R1's LSP. R2 can just start
> 	> using the pseudonode nickname, and if the link is partitioned,
> R1 will have to acquire a new nickname for
> 	> it's half of the link. (I think this case is safe and
> reasonable)
> 
> 
> 	Yes, it is reasonable and feasible.
> 
> 	But I think a purging mechanism by prematuring the stale DRB's
> psedo-nickname is required when the old DRB is not in the new DRB's
> neighbor list.
> 
> 	Assumed that there are 4 hosts(H1,H2,H3 and H4) and 4
> RBridges(RB1, RB2, RB3 and RB4, RB1 is DRB) on the initial link E1,
> which pseudo-nickname is PseNick1. A remote RBridge Rn has learned that
> the egress to H1,H2,H3 and H4 is PseNick1,and the RBn's shortest path
> to PseNick1 is through RB1. Now if the link partitions into two halves,
> RB1,RB2 and H1,H2 on the left half, the others on the right. If not
> purge the RB1's psedo-nickname from TRILL campus, RBn cannot remove(or
> update) the entries of H1,..H4 in it's forwarding table(until receiving
> traffic from H1,..,H4), even if one half link selects another psedo-
> nicknamee (for examble the right half). Then the traffic to H3 or H4 is
> discarded at the floor hop. However, if the RB1's psedo-nickname is
> purged from TRILL, RBn can remove the associated entries from
> forwarding table, and sends the frames destined to H3 or H4 as unkown
> unicast frames, which confirms these frames reach H3 or H4.
> 
> 	After introducing such a purging mechanism, the processing of
> pseudo-nickname for DRB change(including link partition) is as
> following:
> 
> 	From neighbor's Hellos or the pseu-nickname stored locally, the
> new DRB can know the pseudo-nickname used before on this link. With
> this pseudo-nickname as key, it can look up the associated pseudo LSP
> from its LSDB. If found, the new DRB purges this LSP from the TRILL
> campus if the older DRB is not in the new DRB's neighbor list. After
> that, or if not found, the new DRB contends for this nickname by common
> LSP. If successfully obtains this nickname, it can annouce this
> nickname in its pseudo LSPs and using it in data plane. Otherwise, it
> MUST contend for another nickname as pseudo nickname. Before obtaining
> a pseudo-nickname sucessfully, DRB MUST not use pseudo-nickname in
> ingressing frames into TRILL campus.
> 
> 	In brief, the key words are "Purging older DRB's pseudo LSP"
> firstly, "Contending for the pseudo-nickname" secondly, "Announcing the
> obtained pseudo-nickname in pseudo LSP", and "Using this pseudo-
> nickname in data plane" finally.
> 
> 
> 
> 
> 	Thanks,
> 	Zhai Hongjun
> 	"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> """""
> 	Development Dept.VI, Central R&D Institute, ZTE Corporation
> 	No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China,
> 210012
> 
> 	Zhai Hongjun
> 
> 	Tel: +86-25-52877345 <tel:%2B86-25-52877345>
> 	Email: [email-masked]
> 	"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> """"""
> 
> 
> 
> 
> 
> Radia Perlman <[email-masked]>
> 
> 发件人:  [email-masked]
> 
> 2011-07-27 23:13
> 收件人
> [email-masked]
> 抄送
> [email-masked], [email-masked], Erik Nordmark
> <[email-masked]>
> 主题
> Re: [rbridge] Pseudo-node nickname
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 	2011/7/27 <[email-masked] <mailto:[email-masked]> >
> 
> 	The point is that there maybe two cases  that R2 loses
> conncetitvty to R1: one is R1 is died, and the other is  the link
> partitioning.
> 
> 	If the link is partitioned , R2 Must not purge R1's LSP.
> 
> 	The problem is, it's hard for R2 to know that R1 is still alive,
> but the link partitioned (that was Erik's original point).  In either
> case (R1 is dead, or the link partitioned), R2 will stop hearing Hellos
> from R1, but R1's LSP will not have timed out.  So the possibilities
> are
> 
> 	a) wait "awhile", upon taking over as DRB, before getting a
> nickname for the pseudonode.  Note that if R1's LSP hasn't expired, and
> R1's priority is higher, R2 cannot legally use the nickname for the
> pseudonode.
> 	b) if after "awhile" there is no path through current LSPs, to
> R1's LSP, then purge *that* LSP of R1's.  (i.e., only do it once)
> 	c) if R2 has higher nickname priority than R1, then R2 doesn't
> need to purge R1's LSP.  R2 can just start using the pseudonode
> nickname, and if the link is partitioned, R1 will have to acquire a new
> nickname for it's half of the link.  (I think this case is safe and
> reasonable).
> 	d) don't bother reusing nicknames if the DRB changes, but note
> that AF changes will still be helped by this (the simplest case).
> 
> 	Perhaps there are other possibilities.  But I think it's safe to
> do c).  The disadvantage of not doing b) is that if R1's pseudonode has
> higher priority than R2's pseudonode then if R1 dies (more likely than
> the link partitioning probably), R2 doesn't get to reuse the nickname.
> But I'm sure people will worry about allowing R2 to purge someone
> else's LSP, so only doing c)  (allowing R2 to take over the nickname if
> R2's pseudonode has higher nickname priority), is reasonable.
> 
> 	Radia
> 
> 
> 
> 	 _______________________________________________
> 	rbridge mailing list
> 	[email-masked]
> 	http://mailman.postel.org/mailman/listinfo/rbridge
> 
> 
> 
> 	--------------------------------------------------------
> 	ZTE Information Security Notice: The information contained in
> this mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated to
> maintain secrecy and are not permitted to disclose the contents of this
> communication to others.
> 	This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the originator of the message. Any views expressed in this message are
> those of the individual sender.
> 	This message has been scanned for viruses and Spam by ZTE Anti-
> Spam system.
> 

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

---

From: [email-masked]
Date: Fri, 12 Aug 2011 17:46:35 +0800

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

In TRILL, there are two forwarding tables in data plane for unicast data 
frame. The first is MAC forwarding table, the entry in this table has the 
forming of {Dest_MAC, VLAN-ID, Egress_Nickname}. The second is TRILL ECMP 
table, whose entry has the form of {Egress_nickname, out_port, 
next_hop_mac,...}. The information in the first table is obtained by 
self-learning when decapsulating TRILL data frames. The second table is 
established from the TRILL LSPs. Only if an RBrige is reachable in ECMP 
table, the entry using this RBridge as egress can be added into MAC 
forwarding table. On the other hand, when an RBridge is un-reachable, the 
entry using this RBridge as egress must be removed from MAC forwarding 
table.

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

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

It is difficult for an RBridge to distinguish between DRB down and LAN 
partition, but it is easy for an RBridge to find conflict in nickname, 
especially in pseudo-node nickname used by its own. In issue of LAN 
partition, pseudo-node nickname conflict will be detected by DRBs at two 
part of partitioned LAN. After elected as new DRB, the RBridge just reuses 
the pseudo-node nickname already existing on the link in its pseudo-node 
LSPs. Once it detects pseudo-node nickname conflict issue occurs, in which 
another RBridge uses the same pseudo-node nickname in pseudo-node LSPs as 
its own, it will use the above mechanism to eliminate this conflicting.

Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: [email-masked]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

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

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

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

> nickname in data plane" finally.
alive,

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge