Subject: Re: [rbridge] Proposed compromise for short/long hellos

From: [email-masked]
Date: Wed, 01 Apr 2009 12:05:10 +0100

Mike,

The text you quoted does imply different behavior than TRILL has to have.
I don't know if the behavior I'd assumed for IS-IS got lost in translation from DECnet, or perhaps
actually specified that way for DECnet, but at any rate,  even though the behavior isn't what
I remembered it as being,
that behavior is OK for layer 3 IS-IS, where having multiple DRBs on a link is not fatal.

But it is *not* OK for TRILL.

Even with the extra phrase (clause 8.4.5) you quoted, that would still be fatal
behavior for TRILL. It could be that R1 has highest (numerically lowest?) priority
for being DRB, but R2 and R3 can't handle the MTU, or don't communicate on
R1's designated VLAN, or whatever, and then R2 and R3 could still have
an 'adjacency' to each other, so R2 might decide it, too, is DRB. There might be
an R4 that R1 does have an 'adjacency' to, so both R1 and R2 would decide
to be DRBs.

And even if there is no other 'up' adjacency, and there's only a single RBridge, say R1,
on a link, R1 has to become the designated forwarder, and act like the DRB on
that link, except it doesnt' have to send CSNPs of forward LSPs (no RBridge neighbors).

So regardless of the terminology of what it means to 'have an adjacency' or
'be DRB', TRILL IS-IS has to behave like I said in the previous emails -- regardless
of whether R1 (the DRB) can hear you, for whatever reason it might not be able to
hear you (VLAN mismatch, MTU mismatch, one-way connectivity due to bizarre hardware),
you MUST NOT try to also become DRB.

For TRILL, we have to be super conservative to make sure that multiple RBridges are not
attempting to become Designated Forwarder on the same link. So if R2 can hear R1, and
R1's hellos indicate it would win the DRB election, R2 MUST defer to R1.

Radia

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

---

From: mike shand <[email-masked]>
Date: Wed, 01 Apr 2009 12:48:07 +0100

Radia,

    So would it make more sense to leave the hellos, adjacency 
establishment rules, DIS election exactly as it is for IS-IS and use 
THAT for the IS-IS related stuff like generating pseudonodes, running 
the LAN reliable update process and advertising connectivity, and then 
have a new small TRILL hello which behaved the way you described and use 
that for electing the DRB from the point of view of determining who does 
the forwarding?

    Mike

---

From: "Hari Balasubramanian (harih)" <[email-masked]>
Date: Wed, 1 Apr 2009 09:42:15 -0700

>  that behavior  is OK for layer 3 IS-IS, where having multiple DRBs on
a link 
> is not fatal.

Radia, I am not sure if I understand why having multiple DRBs on a link
for Layer 3 is ok ( or "not fatal")? Can you explain a bit?

Thanks, Hari

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, April 01, 2009 4:05 AM
> To: Mike Shand (mshand)
> Cc: TRILL/RBridge Working Group
> Subject: Re: [rbridge] Proposed compromise for short/long hellos
> 
> Mike,
> 
> I don't know if the behavior I'd assumed for IS-IS got lost 
> in translation from DECnet, or perhaps actually specified 
> that way for DECnet, but at any rate,  even though the 
> behavior isn't what I remembered it as being, that behavior 
> is OK for layer 3 IS-IS, where having multiple DRBs on a link 
> is not fatal.
> 
> Even with the extra phrase (clause 8.4.5) you quoted, that 
> would still be fatal behavior for TRILL. It could be that R1 
> has highest (numerically lowest?) priority for being DRB, but 
> R2 and R3 can't handle the MTU, or don't communicate on R1's 
> designated VLAN, or whatever, and then R2 and R3 could still 
> have an 'adjacency' to each other, so R2 might decide it, 
> too, is DRB. There might be an R4 that R1 does have an 
> 'adjacency' to, so both R1 and R2 would decide to be DRBs.
> 
> And even if there is no other 'up' adjacency, and there's 
> only a single RBridge, say R1, on a link, R1 has to become 
> the designated forwarder, and act like the DRB on that link, 
> except it doesnt' have to send CSNPs of forward LSPs (no 
> RBridge neighbors).
> 
> So regardless of the terminology of what it means to 'have an 
> adjacency' or 'be DRB', TRILL IS-IS has to behave like I said 
> in the previous emails -- regardless of whether R1 (the DRB) 
> can hear you, for whatever reason it might not be able to 
> hear you (VLAN mismatch, MTU mismatch, one-way connectivity 
> due to bizarre hardware), you MUST NOT try to also become DRB.
> 
> For TRILL, we have to be super conservative to make sure that 
> multiple RBridges are not attempting to become Designated 
> Forwarder on the same link. So if R2 can hear R1, and R1's 
> hellos indicate it would win the DRB election, R2 MUST defer to R1.
> 
> Radia
> 
>

---

From: Radia Perlman <[email-masked]>
Date: Wed, 01 Apr 2009 17:33:31 -0700

> for Layer 3 is ok ( or "not fatal")? Can you explain a bit?

Suppose there is a link with 4 routers: R1, R2, R3, and R4, and for 
whatever reason, R1 and R2
have 2-way connectivity with each other, and R3 and R4 have 2-way 
connectivity with each other.

It would be OK for R1 and R3 to both become DRBs, create a pseudonode 
for the link, and to routers
distant from the link, based on LSPs, it would look like 2 links; one 
that connects R1 and R2, and
one that connects R3 and R4. The two cliques ({R1, R2}, and {R3, R4}) 
would pretty much
ignore each other.

Both R1 and R3 would be sending CSNPs.

I don't see any harm from this behavior.

Even if, say, R5 were part of both cliques (but R5 is not DRB in either 
clique), I don't see a problem.
I presume (I'd have to read, or be pointed to, the exact wording of the 
IS-IS spec) that R5, in this case
would either
a) choose to be part of one clique and ignore the other one, or
b) claim to be connected to both "R1.x" and "R3.y".

Mike? Do you know which thing would happen?

But at any rate, I don't see any problem caused by either of those cases 
(on the other hand, I'm in an airport
lounge having just flown transatlanticly, and not slept recently, so 
there might be a problem with it).

But I definitely know that with TRILL it would be a big problem.

Radia

---

From: mike shand <[email-masked]>
Date: Thu, 02 Apr 2009 09:25:57 +0100

Radia Perlman wrote:

Thanks, Hari

Yes, even to the extent that in theory they wouldn't see each other's
LSPs, since you are supposed to only accept an LSP from a neighbor to
which you have an up adjacency. So this would mean that all LSPs would
get propagated twice over the LAN. However, I think many
implementations ignore this requirement.

So its not desirable, but its not fatal, as Radia says.

If R5 forms an adjacency to both the R1 clique and the R3 clique it
will decide which of R1 and R3 it thinks is DIS (on the basis of
ID/priority as usual, and will claim connectivity to that pseudonode.
Suppose it is R1. However, since both R1 and R3 have adjacencies to R5,
they will BOTH claim connectivity in their pseudonode LSPs to R5.

When someone runs an SPF, they will find that the bidirectional
connectivity check fails for the R5, R3.y link, so it will be ignored.
So it will appear that R5 is only connected to R1 and R2 on the LAN.

Again, not perfect, but it doesn't actually break anything.

Mike

(just off the top of my head, but I THINK it is right.)

Radia

---

From: "Hari Balasubramanian (harih)" <[email-masked]>
Date: Fri, 3 Apr 2009 08:26:57 -0700

Please see inline.... 

> From: Radia Perlman [mailto:[email-masked]] 
> Sent: Wednesday, April 01, 2009 5:34 PM
> To: Hari Balasubramanian (harih)
> > Radia, I am not sure if I understand why having multiple DRBs on a 
> > link for Layer 3 is ok ( or "not fatal")? Can you explain a bit?
> >
> > Thanks, Hari
> >
> >   
> 
> Suppose there is a link with 4 routers: R1, R2, R3, and R4, 
> and for whatever reason, R1 and R2 have 2-way connectivity 
> with each other, and R3 and R4 have 2-way connectivity with 
> each other.
> 
> It would be OK for R1 and R3 to both become DRBs, create a 
> pseudonode for the link, and to routers distant from the 
> link, based on LSPs, it would look like 2 links; one that 
> connects R1 and R2, and one that connects R3 and R4. The two 
> cliques ({R1, R2}, and {R3, R4}) would pretty much ignore each other.
> 

 Is there not a possiblity of duplicate packets being sent out (for
multicast packets) as both R1 & R3 believe they are the DR for the LAN?
Are you suggesting that duplicate packets are ok as long as they don't
cause loops (as it would in TRILL under similar conditions, I think)?

> Even if, say, R5 were part of both cliques (but R5 is not DRB 
> in either clique), I don't see a problem.
> I presume (I'd have to read, or be pointed to, the exact 
> wording of the IS-IS spec) that R5, in this case would either
> But at any rate, I don't see any problem caused by either of 
> those cases (on the other hand, I'm in an airport lounge 
> having just flown transatlanticly, and not slept recently, so