Subject: [rbridge] Pseudo-node nickname

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Jul 2011 12:01:16 -0700

A few questions that I didn't bring up in the meeting since we were 
short on time.

You said that the pseudo-node nickname is not used for multicast.
Is that a statement about the destination nickname (which identifies the 
tree)? Or is it also a statement about the source nickname?
I would assume the source nickname would be a pseudo-node even for 
multidestination frames, since the egress rbridges would learn from the 
source nickname.

Currently TRILL can handle a link being partitioned as long as there is 
at least one RBridge in each partition; a DRB will be elected for each 
partition.
With pseudo-node nicknames this adds some complexity. I think each DRB 
will need to pick a unique pseudo-node nickname after they detect a 
partition of the link (but how do they reliably detect the difference 
between a RB failure and a partitioned link?). If they don't packets 
will be routed to an egress RBridge which thinks it is attached to the 
same link as the endnode, even though it isn't due to the endnode being 
in the other half of the partitioned link. Hence packets will be dropped 
on the floor.

Perhaps you can clarify those parts.

Thanks,
     Erik

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

---

From: Radia Perlman <[email-masked]>
Date: Mon, 25 Jul 2011 18:38:11 -0700

1) Yes, I believe that the pseudonode nickname will be used as the
ingress nickname for both unicast and multidestination.

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

3) Indeed, once a nickname changes, whether it's a pseudonode nickname
or an RBridge nickname, all the remote RBridges that have made mapping
entries for (MAC, nickname) for the old nickname will have incorrect
entries. So this draft is attempting to make the situation where the
AF changes not disrupt such tables, at the expense of having tables
become incorrect when a pseudonode partitions.  I'd assume that AF
changes are more frequent than pseudonode partitions.

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

Radia

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 26 Jul 2011 06:50:31 -0700

> ingress nickname for both unicast and multidestination.

OK

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

> Since both halves will try to reuse the

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

> changes are more frequent than pseudonode partitions.

Agreed.

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

Thanks,
    Erik

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 26 Jul 2011 10:42:31 -0400

Hi Erik,

> which case R1 or R2 needs to pick a new pseudo-node nickname).

I'm not sure what the problem is. R2 can't tell the difference between
R1 dying and the link dying. If R2 is higher nickname priority than
R1, R2 keeps the nickname if it creates a pseudonode. I don't think
there is any reason to generate a pseudonode if you think you are the
only RBridge on a link. If R2 lower nickname priority, it get a new
nickname. (Nickname priority is unrelated to DRB priority.)

When there are two copies of the same nickname being advertised in the
topology, frames with that value as egress nickname are sent to the
one that is least cost away.

> MAC SA for the pseudo-node, so I hope that isn't necessary.)

The RPF check is only based on input port, ingress nickname, and tree
(i.e., egress nickname). [Check 2 in Section 4.5.2 of RFC 6325]

There is a separate check of the Outer.MacSA on Ethernet links that
the frame came from a tree adjacency. [Check 1 in Section 4.5.2 of RFC
6325] While that section of the RFC is not crystal clear on this
point, it only makes sense when applied to physical RBridge
adjacencies.

>    Erik

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 26 Jul 2011 07:58:02 -0700

> nickname. (Nickname priority is unrelated to DRB priority.)

Let me try explaining what I see as a potential issue.
If R2 is lower nickname priority, then to handle a partition R2 needs to 
pick a new pseudo-node nickname when there is a link partition. If R2 
can't tell the difference between a link partition and R1 failing, then 
R2 will need to create a new pseudo-node nickname even when R1 fails.

*If* that is the case, then there are no significant benefits of 
pseudo-node nicknames; upon an RBridge failure nickname to use to reach 
some endnodes will change.
Hence my question is how can R2 reliably tell whether R1 failed, and the 
link between R1 and R2 failed but R1 is still alive.

> one that is least cost away.

Sure; that isn't the potential issue above.

> point, it only makes sense when applied to physical RBridge

OK, so that description would need to be tweaked if the tree includes 
pseudo-nodes; presumably any outer.macsa from two hops earlier in the 
tree should be OK if one hop earlier is a pseudo-node.

    Erik

---

From: Radia Perlman <[email-masked]>
Date: Tue, 26 Jul 2011 08:00:49 -0700

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

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

> 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

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 26 Jul 2011 12:05:12 -0400

Hi Erik,

On Tue, Jul 26, 2011 at 10:58 AM, Erik Nordmark <[email-masked]> wrote:
> pick a new pseudo-node nickname when there is a link partition. If R2 can't
> tell the difference between a link partition and R1 failing, then R2 will
> need to create a new pseudo-node nickname even when R1 fails.
>
> *If* that is the case, then there are no significant benefits of pseudo-node
> nicknames; upon an RBridge failure nickname to use to reach some endnodes
> will change.

You're right...

What I would say is that R2 should wait a little while. The LSPs from
R1 will take a long time to time out if R1 dies. However, assuming R1
was multiply connected to the campus, other neighbors of R1 on other
links will lose adjacency to R1 so there should be a burst of updates
to the LSPs for various Rn showing they are no longer connected to R1.
On the other hand, if it is just that the link between R1 and R2 dies,
then R1's adjacencies with other RBridges will remain stable.

> pseudo-nodes; presumably any outer.macsa from two hops earlier in the tree
> should be OK if one hop earlier is a pseudo-node.

Yes, although I would say clarified rather than tweaked. Of course,
from the fact that the seventh byte of its ID is non-zero, it is easy
to tell if a real node is a pseudo-node.

Thanks,
Donald

---

From: [email-masked]
Date: Wed, 27 Jul 2011 14:25:05 +0800

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]> 
发件人:  [email-masked]
2011-07-26 23:00

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

> Is there a different mechanism if the link originally had just {R1, R2}, 
and

> Suppose R1 and R2 where on the link originally, with R1 being the DRB 
for
> R2 stops hearing the IS-IS hellos from R1 on the link, and as a result 
R2
> At this point in time, even if R1 died, the LSPs that had previously 
been

------[by zhai]
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.

----- 
> pseudo-node? (One can't tell from the frame since there isn't a outer 
MAC SA

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 06:20:16 -0700

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

> this LSP(maybe the old DRB on this link) is dead, then it can use the above
>
>   *Radia Perlman <[email-masked]>*
>
> 2011-07-26 23:00
>    收件人
> Hu Fangwei <[email-masked]>, Zhai Hongjun <[email-masked]>,
> [email-masked]
> 主题

---

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

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

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

and

for
R2
been

MAC SA

Radia

---

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

I agree with Radia, the point being discussed is that R2  can not tell the 
difference between R1 having died and R1 being alive and the link 
partitioned. That is the point.

I think the solution a) is good: don't reuse the pseudonode nickname if 
the DRB changes. 

That is a simple solution, and the draft should be modified and 
simplified,the other RBridges except DRB should not announce its 
pseudonode nickname TLV in its LSPs, 

they only announce its pseudonode nickname capabilities. 

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

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人
Erik Nordmark <[email-masked]> 
抄送
Hu Fangwei <[email-masked]>, Zhai Hongjun <[email-masked]
>, [email-masked] 
主题

and

for
R2
been

MAC SA

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.

---

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

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

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.

收件人
[email-masked]
抄送

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.

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人
主题

and

for
R2
been

MAC SA

Radia

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Jul 2011 07:52:25 -0700

On 7/27/11 6:30 AM, [email-masked] wrote:
> 
> I agree with Radia, the point being discussed is that R2 can not tell 
> the difference between R1 having died and R1 being alive and the link 

But doesn't that reduce the utility of the pseudo-node nickname?
If R1and R2 attach to a link and R1 is the current DRB (and also AF for
all the VLANs on that link), then without pseudo-node nicknames the R2
can fail without any change - all the remote RBridges will send packets
to R1's nickname.
But if R1 fails the remote RBridges would need to re-learn.

If we add pseudo-node nicknames and don't reuse it when the DRB changes,
don't we have exactly the same behavior?

(There might be differences if the DRB is not AF for all the VLANs, but
I'm first trying to userstand the behavior when the DRB is AF for all.)

   Erik

> 2011/7/27 <[email-masked] <mailto:[email-masked]>>
> 
> Tel: _+86-25-52877345_ <tel:%2B86-25-52877345>
> Email: [email-masked] <mailto:[email-masked]>
> *Radia Perlman <[email-masked]* 
> <mailto:[email-masked]>*>*
> 
> 2011-07-26 23:00
> 
> 	
> 收件人
> 	Erik Nordmark <[email-masked] <mailto:[email-masked]>>
> 抄送
> 	Hu Fangwei <[email-masked] <mailto:[email-masked]>>, 
> Zhai Hongjun <[email-masked] 
> <mailto:[email-masked]>>, [email-masked] 
> <mailto:[email-masked]>
> 主题
> On Tue, Jul 26, 2011 at 6:50 AM, Erik Nordmark <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 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.