Subject: [rbridge] "Access port"

From: Anil Rijhsinghani <[email-masked]>
Date: Thu, 18 Feb 2010 15:14:08 -0500

The draft describes possible configuration of an "access port" which
connects to end stations and/or bridges but not Rbridges. On such
ports, Rbridges will send no Trill frames with the exception of hellos.

My question is: should an Rbridge automatically sense an access port, if
it receives no Trill hellos off it?

That is, can a port become an access port without configuration using
this method? That would be a nice feature.

Regards,
Anil

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 18 Feb 2010 16:24:32 -0500

Hi Anil,

> ports, Rbridges will send no Trill frames with the exception of hellos.

Actually, I would say that the main idea is to only provide end station
service. An alternative name used in the draft for an access port is "TRILL
traffic disable". It's fine for an end stations and/or bridges to be
connected to an access port on each of two or more RBridges, for example to
provide reliable service in case one of the RBridges is down. So, in such
cases the access ports on the RBridges are connect to another access port on
another RBridge. Providing end station service only on an access port, you
don't want to send any TRILL data or LSPs/SNPs through such a port. But you
have to send TRILL Hellos for safety in case another RBridge gets connected
to the link, or the like.

> it receives no Trill hellos off it?

I don't think it should do anything special. If it has not seen any TRILL
Hellos, there won't be any adjacencies and so no TRILL data frames will be
sent. As to whether IS-IS normally sends LSPs/SNPs on port where there are
no adjacencies, I don't see why it would send them. But that seems like an
IS-IS issue...

> this method? That would be a nice feature.

What exactly would be the benefit?

Thanks,
Donald

---

From: Anil Rijhsinghani <[email-masked]>
Date: Thu, 18 Feb 2010 16:43:07 -0500

Donald,

Whatever the benefits of configuring a port as "access" would also ensue from this.

For such ports, you wouldn't need to "inhibit" regardless of changing STP roots, for one.

For another, multi-destination traffic would need to be sent out only in native form, not encapsulated -- else as I understand, you could be sending out two copies of each multicast packet (one in each form) as described in 4.6.1.2.

I agree if you had 2 Rbridges attached to a link for redundancy reasons, you can't auto-detect this way. But there'll be many links where this isn't the case.

Regards,
Anil

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 18 Feb 2010 17:02:19 -0500

Hi Anil,

> Whatever the benefits of configuring a port as "access" would also ensue

I think the only benefit is stopping the transmission of TRILL data and
TRILL IS-IS frames, except TRILL Hellos, even when there are adjacencies.

> For such ports, you wouldn't need to "inhibit" regardless of changing STP

But what if the STP root change is because of the merger of two bridged
LANs? Say you are an RBridge attached to bridged LAN A and a cable gets
plugged in merging bridged LAN A with bridged LAN B and there are one or
more RBridges already attached to bridged LAN B. If you and one of the other
RBridges are appointed forwarder for the same VLAN, there will be a loop
until TRILL Hellos get sent through and straighten things out. This loop
only involves native frames on the merged bridged LAN. So, as far as I can
see, you do need to inhibit on STP root change on an access port.

> For another, multi-destination traffic would need to be sent out only in
> native form, not encapsulated -- else as I understand, you could be sending
> out two copies of each multicast packet (one in each form) as described in
> 4.6.1.2.
>

A multidestination native frame is encapsulated and then sent on ports that
are part of the distribution tree selected by the ingress RBridge. A port
with no adjacencies on which TRILL data frames can be sent cannot have a
branch of a distribution going through it, since there is nothing to be the
next hop. This will be true if the port is an access port. But it only makes
a difference if there actually are adjacencies, because the "access port"
state will stop the inclusion of those adjacencies in the pool of
adjacencies form which distribution trees are built. If there actually are
no adjacencies, then no encapsulated data will be sent out the port
regardless of whether it is flagged as an access port or not.

> I agree if you had 2 Rbridges attached to a link for redundancy reasons,
> you can't auto-detect this way. But there'll be many links where this isn't
> the case.
>

OK, I'll believe there will be many links like that. But I still can't see
any benefit to labeling a port an access port if there are not adjacencies
on it. It only helps to label a port an access port if there are, or might
in the future be, IS-IS adjacencies on it.

Thanks,
Donald

---

From: James Carlson <[email-masked]>
Date: Thu, 18 Feb 2010 17:32:01 -0500

> this method? That would be a nice feature.

I think that may miss the point.

The intention of "Access Port" functionality was to prevent TRILL
forwarding on particular ports when so configured, even if such
forwarding would be advantageous in some situation.  There are
operational cases where this mechanism is necessary, and administrators
will want to configure certain ports as not allowing TRILL-based
forwarding no matter what.

If you want to "automatically" go in and out of access port mode, then
you don't need this mechanism at all.  Just run normal TRILL, and omit
the configuration variable.  A normal TRILL bridge will do exactly as
you're asking.  You don't need this feature if you don't want it.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Anil Rijhsinghani <[email-masked]>
Date: Thu, 18 Feb 2010 19:02:29 -0500

> Actually, I would say that the main idea is to only provide end  
> station service. An alternative name used in the draft for an access  
> port is "TRILL traffic disable". It's fine for an end stations and/ 
> or bridges to be connected to an access port on each of two or more  
> RBridges, for example to provide reliable service in case one of the  
> RBridges is down. So, in such cases the access ports on the RBridges  
> are connect to another access port on another RBridge. Providing end  
> station service only on an access port, you don't want to send any  
> TRILL data or LSPs/SNPs through such a port. But you have to send  
> TRILL Hellos for safety in case another RBridge gets connected to  
> the link, or the like.

I guess this really is the only benefit - don't allow such links to be  
on the shortest path for any destination. Although in a well-designed  
network, I don't see this sort of thing happening anyway.

I was reverse-engineering - assuming there's some benefit to an access  
link, I was trying to auto-detect one :)

Thanks for the response,
Anil