[rbridge] Pseudo-node nickname

[Radia Perlman]

And certainly if we do that (have R2 purge R1's LSP), we'd have to make sure
that R2 would only purge R1's LSP once after losing Hello connectivity to
it,
so if R1 were really alive, R2 wouldn't keep trying to stomp on its LSP.

Radia




2011/7/27 <zhai.hongjun at zte.com.cn>

>
> > Good point.  I think there are various possibilities then
>
> > a) don't reuse the pseudonode nickname if the DRB changes (since R2
> > can't tell the difference between R1 (the DRB) being down vs the link
> > partitioning and R1 still using the pseudonode nickname for R1's
> > partition.  However, the pseudonode nickname will still be valuable
> > when there is an AF change (for instance, the old AF died), but the
> > DRB is still alive so it's clear it's still the same link.
>
> > b) try to detect that R1 is dead vs the link partitioned, for
> > instance, by delaying a bit before acquiring a nickname for the new
> > pseudonode, and then noticing that R1, although the LSP still exists,
> > is not reachable when running the SPF calculation using the LSP
> > database.  And then saying that it's OK to use the same nickname as
> > unreachable R1.
>
> > Certainly a) is safe, and simple, and helps in some cases (AF dies but
> > DRB remains), and is no worse in the case where the DRB dies than not
> > trying to reuse the nickname.
>
> The following mechanism of prematuring other RBridges's LSP can solve
> these problem.
> After an new DRB is elected, the DRB find the pseudonode nickname used
> before
> on the link from its neighbor Hellos, it looks up its LSDB to find
> whether other RBridge has announced this nickname in pseudonode LSPs.
> If not found, it can use this pseudonode nickname safely. Otherwise, it
> will
> try to purge this pseudonode LSP in trill campus by prematuring this LSP.
> If a new copy (with higher sequence number) of the LSP can not be received
> during a period time, the new DRB can confirm that the originator of
> this LSP(maybe the old DRB on this link) is dead, then it can use the above
>
> pseudonode nickname safely. Otherwise, the new DRB must use a new
> pseudonode
> nickname on this link.
>
> The above mechanisem can work for the case of link partition and
> the case of new DRB on same link.
>
>
>
> 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>*
>
> 2011-07-26 23:00
>    ÊÕ¼þÈË
>  Erik Nordmark <nordmark at acm.org>
>  ³­ËÍ
> Hu Fangwei <hu.fangwei at zte.com.cn>, Zhai Hongjun <zhai.hongjun at zte.com.cn>,
> rbridge at postel.org
> Ö÷Ìâ
> Re: [rbridge] Pseudo-node nickname
>
>
>
>
> On Tue, Jul 26, 2011 at 6:50 AM, Erik Nordmark <nordmark at acm.org> wrote:
> >> 2) If there is a partition of the link, such that, say, {R1, R2} are
> >> in one partition, and {R3, R4} are in the other partition, then the
> >> link becomes two links.
> >
> > Is there a different mechanism if the link originally had just {R1, R2},
> and
> > the partition results in there being a single RBridge attached to each
> > partition?
>
> I don't believe so.  I think it works whether there's a single RBridge
> or multiple of them in the partition.
>
>
> >
> >> Since both halves will try to reuse the
> >> nickname that the single link had been using, both halves will use the
> >> same nickname.  However, as soon as an LSP from the DRB on one side of
> >> the partition reaches the DRB on the other side of the partition, it
> >> will detect a duplicate nickname use, and based on the priority of the
> >> DRB, one side or the other will relinquish the nickname and choose
> >> another one.
> >
> > Can there be race conditions in this part of the protocol?
> > Suppose R1 and R2 where on the link originally, with R1 being the DRB for
> > the link.
> > R2 stops hearing the IS-IS hellos from R1 on the link, and as a result R2
> > gets elected to be DRB. Note that this can happen in two different cases:
> R1
> > died or the link between R1 and R2 was cut.
> > At this point in time, even if R1 died, the LSPs that had previously been
> > originated by R1 will not have timed out. Thus won't R2 think that R1 is
> > still alive? How and when can R2 reliably tell the difference between R1
> > having died (in which case it can continue with the same pseudo-node
> > nickname) and R1 being alive and the link partitioned (in which case R1
> or
> > R2 needs to pick a new pseudo-node nickname).
>
>
> Good point.  I think there are various possibilities then
>
> a) don't reuse the pseudonode nickname if the DRB changes (since R2
> can't tell the difference between R1 (the DRB) being down vs the link
> partitioning and R1 still using the pseudonode nickname for R1's
> partition.  However, the pseudonode nickname will still be valuable
> when there is an AF change (for instance, the old AF died), but the
> DRB is still alive so it's clear it's still the same link.
>
> b) try to detect that R1 is dead vs the link partitioned, for
> instance, by delaying a bit before acquiring a nickname for the new
> pseudonode, and then noticing that R1, although the LSP still exists,
> is not reachable when running the SPF calculation using the LSP
> database.  And then saying that it's OK to use the same nickname as
> unreachable R1.
>
> Certainly a) is safe, and simple, and helps in some cases (AF dies but
> DRB remains), and is no worse in the case where the DRB dies than not
> trying to reuse the nickname.
>
> >
> >> 4) There was a question (not in Erik's email, but privately to me and
> >> so I might as well answer it while I'm writing an email) about whether
> >> a pseudonode nickname as ingress could mess up the RPF check on
> >> multidestination frames.  I believe the answer to that is "no",
> >> because it is a tree.  For instance, assume a simple topology where a
> >> pseudonode has 3 RBridges, R1, R2, and R3, and each of those has one
> >> other port to the greater TRILL cloud.  So given that it is a tree,
> >> one likely scenario is that only one of them, say R1, has their
> >> up-link chosen to be in the tree, and R2 and R3 are only attached to
> >> the tree via the pseudonode.  In that case, if R2 or R3 initiates the
> >> multidestination frame, it is only allowed to send it to the
> >> pseudonode (their up-link is not in the tree), and so it will only be
> >> R1 that will forward the frame into the cloud.  It's possible though
> >> that the pseudonode is actually "in the middle of" the tree.  For
> >> instance, the pseudonode might even be the tree root, in which case
> >> all of R1, R2, and R3 have their up-link turned on for that tree.  But
> >> that's OK.  But the definition of a tree, any given RBridge, say R4,
> >> will only receive the packet from the pseudonode from one direction.
> >> I'm sure a picture would help, but I'm too lazy right now.  :-)
> >
> > Does this mean that the RPF check needs to be able to verify whether a
> > multidestination frame came from pseudo-node (the previous hop was the
> > pseudo-node) as opposed to from a particular RBridge attached to the
> > pseudo-node? (One can't tell from the frame since there isn't a outer MAC
> SA
> > for the pseudo-node, so I hope that isn't necessary.)
> >
>
> No.  The pseudonode is just a regular ingress node, so I don't think
> the RPF check needs
> to be aware that the ingress is a pseudonode or a regular node.  It's
> just that in calculating the tree, the
> pseudonode has to be a regular node, and the DRB has to announce in
> the pseudonode LSP which trees
> the pseudonode might choose when it is ingressing.  (I assume that's
> already there, but I haven't checked).
>
> Radia
>
>
>
>  --------------------------------------------------------
> 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/20110727/993d11b8/attachment.html