Subject: Re: [rbridge] Pseudo-node nickname

From: [email-masked]
Date: Wed, 27 Jul 2011 21:50:39 +0800

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.

ZhaiHongJun129567/user/zte_ltd
2011-07-27 21:38

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

> 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. 

Yes, right. It is not difficult to make sure that R2 would only purge R1's 
LSP once after losing Hello connectivity to it, for example, start a 
non-cyclical timer to control the prematuring of R1's pseudonode LSP. 

Radia Perlman <[email-masked]> 
2011-07-27 21:20 

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

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. 

2011/7/27 <[email-masked]> 

> 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: [email-masked]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Radia Perlman <[email-masked]> 
2011-07-26 23:00 

收件人
Erik Nordmark <[email-masked]> 
抄送
Hu Fangwei <[email-masked]>, Zhai Hongjun <[email-masked]
>, [email-masked] 
主题
Re: [rbridge] Pseudo-node nickname

On Tue, Jul 26, 2011 at 6:50 AM, Erik Nordmark <[email-masked]> 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.

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

---

From: Radia Perlman <[email-masked]>
Date: Wed, 27 Jul 2011 08:13:25 -0700

2011/7/27 <[email-masked]>

> 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

---

From: [email-masked]
Date: Thu, 28 Jul 2011 19:19:54 +0800

>> 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. 

> 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
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

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

 
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

--------------------------------------------------------
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: Radia Perlman <[email-masked]>
Date: Thu, 28 Jul 2011 06:59:22 -0700

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]

> > original point). In either case (R1 is dead, or the link partitioned), R2
> will stop hearing Hellos from R1,
> psedo-nickname is required when the old DRB is not in the new DRB's neighbor
> list.
>
> 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
> 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.
>
> 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.
>
>   *Radia Perlman <[email-masked]>*
> [email-masked], [email-masked], Erik Nordmark <
> [email-masked]>
> 主题
> 2011/7/27 <[email-masked]* <[email-masked]>>
>
> the pseudonode.  Note that if R1's LSP hasn't expired, and R1's priority is
> 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).
> 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
>
>