Subject: [rbridge] "Inter-RBridge-only" port

From: Radia Perlman <[email-masked]>
Date: Fri, 28 Mar 2008 18:57:29 -0700

In this note I'll describe a feature that Anoop suggested (I think he 
originally suggested it).
I think it is a good idea, since I believe it is completely safe, even 
with misconfiguration, and greatly lowers overhead
for those ports so configured.

The idea is as follows:

If port p is configured to be inter-RBridge-only on RB1, then RB1:
a) ignores all traffic that is not TRILL-encapsulated
b) sends IS-IS Hellos only with one VLAN (can we say VLAN 1, 
unconfigurable?)
c) sets a flag in its IS-IS Hello that RB1 considers this port to be 
inter-RBridge only

Why this is a good idea
1) on port p, RB1 only has to send Hellos with one VLAN -- we don't have 
to be super careful about winding up
with two DRBs
2) RB1 only has to listen for Hellos with one VLAN (the one it is 
configured to send on) -- again, it's not tragic if
there are two DRBs -- RB1 just won't form adjacencies with other RBs on 
the cloud that are sending Hellos with
a different VLAN tag
3) if all the RBridges on the cloud are so configured, then unknown 
destination and multicast traffic need not be
decapsulated onto the link.

Why this is not dangerous
a) if R1 is configured this way, and neighbor R2 on the same cloud is 
not...then if R1 is elected DRB, no traffic
will be encapsulated/decapsulated onto the link since R1 will not 
appoint R2 as VLAN forwarder for any VLANs
(all the endnodes on the link will be orphaned)
b) if R2 is configured as inter-RBridge-only on that port and R1, the 
DRB, is not, then again there is no issue -- R1 will
not appoint R2 appointed VLAN forwarder (R1 will be the forwarder)
c) if R1 and R2 are both configured as p=inter-RBridge-only, and R1 is 
configured to send Hellos on a different VLAN
than R2 and they don't see each other's hellos, then they won't form an 
adjacency. But there will be no loops.

I don't care what this feature is called. Proposals for other names have 
been "core", "trunk", "non-access".

Radia

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

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 30 Mar 2008 13:40:15 -0400

Hi,

I agree that being able to have such a "trunk port" is a good idea;
however, I'm not sure it needs any special feature.

In particular, we currently provide that an Rbridge port can be
configured to provide no end station support, that is, to not
decapsulate any native frames onto that link and to ignore any native
frames it receives. And we currently provide that an Rbridge port can be
configured as to what VLANs it sends Hellos on and what VLANs it listens
on. So, as far as I can see, the only actual behavioral change proposed
below is the addition of the "inter-Rbridge" flag in the Hello. This
seems to only be useful in checking for misconfiguration. Perhaps the
thing to do is to possibly re-name the existing "no end-station support"
per port flag to be the "trunk" flag or whatever and report it in the
Hello.

See a few comments below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Friday, March 28, 2008 9:57 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] "Inter-RBridge-only" port

The idea is as follows:

@@@ Actually, it still has to pay attention to control frames like PAUSE
or, if implemented, local link discovery, etc. It just ignores native
frames.

@@@ It might be that a point-to-point link between two Rbridges is
obtained from some provider which just gives you a virtual link in an
arbitrary VLAN, say VLAN 798, so your frames have to use that outer VLAN
ID.

Why this is a good idea

@@@ If this sort of port configuration needs a name, I think "trunk"
would be best.

Radia

@@@ It occurs to me that if a port is configured to provide no end
station support (ignore native frames and not decapsulate), then it
should not contribute to the VLANs advertised by that RBridge in the
link state database. The only reason to advertise the enablement of a
VLAN on one or more ports at an Rbridge is to attract certain
multi-destination encapsulated traffic to that Rbridge but such traffic
will not be decapsulated out such a port. This needs to be mentioned in
the base protocol document.

@@@ We might want to add a note pointing out the desirability of such
trunk port configuration under some circumstances and recommending that
it be made easy to so configure a port. (Summary: enable only VLAN x,
send Hellos only on VLAN x, disable end station support, turn on input
VLAN filtering)

@@@ Thanks,
@@@ Donald

---

From: Radia Perlman <[email-masked]>
Date: Sun, 30 Mar 2008 11:02:51 -0700

> the base protocol document.
Yes. Good point.

---

From: Dinesh G Dutt <[email-masked]>
Date: Sun, 30 Mar 2008 22:21:51 -0700

Hi Donald,

> or, if implemented, local link discovery, etc. It just ignores native
This is where I see a need for a clear demarcation between TRILL and 
IEEE functionality. It's useful to talk about the frames the TRILL 
functionality is concerned with. "Native frames" is not a clear enough 
term IMO.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: Dinesh G Dutt <[email-masked]>
Date: Sun, 30 Mar 2008 22:23:07 -0700

Agreed,

Dinesh

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 31 Mar 2008 09:15:10 -0400

Hi,

This is one reason that there is a (hopefully clear) definition of
"native frames", "control frames", and "TRILL frames" in Section 1.2 of
base protocol draft version -07. But further clarification would
probably be a good idea.

Donald 

-----Original Message-----
From: Dinesh G Dutt [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 1:22 AM
To: Eastlake III Donald-LDE008
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] "Inter-RBridge-only" port

Hi Donald,

Dinesh