Subject: [rbridge] Queries on RFC 6325 - Forming neighbors on L2 access port

From: Abhinav Bhatia <[email-masked]>
Date: Fri, 27 Jan 2012 11:07:27 +0530

Hi,

I have a query regarding forming neighbors between L2 access ports.

"  A TRILL IS-IS frame on an 802.3 link is structured as shown below.
   All such frames are Ethertype encoded.  The RBridge port out of which
   such a frame is sent will strip the outer VLAN tag if configured to
   do so."

If a port is configured as layer 2 access port , then while sending the
trill control frame it will strip off the vlan id.

What should be the behavior on the recieving side (if RBridge), since we
expect trill control frames to be on dvlan or some other vlan , should the
frame be dropped and neighbor is avoided?. If not then how we will come to
know on which vlan the fame has arrived and is there any vlan mapping or
not?

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

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 27 Jan 2012 08:58:03 -0500

Hi Abhinav,

> trill control frame it will strip off the vlan id.

I'm not 100% sure what you mean by "layer 2 access port". There is the
TRILL access port configuration bit, formally known as the TRILL
traffic disable bit, which has to do with stopping the port from being
used by TRILL Data frames and has nothing to do with VLAN labeling.
But I think you mean the 802.1Q port configuration which controls
whether or not there is actually an outer VLAN tag when the frame is
transmitted on the link. These two configurations can be set
independently from each other.

> frame be dropped and neighbor is avoided?.

Just like the 802.1Q customer bridge forwarding function, the
TRILL/RBridge logic and forwarding function have no idea whether the
frame was actually VLAN tagged on the wire. If the received frame
makes it through the lower levels of the port logic, which are the
same for an RBridge and for an 802.1Q customer bridge, by the time it
gets to the higher level logic, there will always be a VLAN ID
associated with it. I'm not sure what "avoiding" a neighbor would
mean.

> If not then how we will come to

The lower layers of RBridge ports are just like 802.1Q customer bridge
ports. The vlan "on which ... the frame has arrived" is just whatever
the EISS interface reports to higher layers. If the frame was untagged
on the link, it is the port VLAN ID. If you have a multi-access link
with multiple RBridge ports on it and those ports are configured
inconsistently as to their port VLAN ID, then the same TRILL frame
that was transmitted untagged will appear to "arrive" on different
VLANs on different ports.
     If the TRILL frame is a TRILL IS-IS Hello frame, then at most one
of such ports could find that the VLAN of the frame matches the saved
copy of the VLAN on which the frame was sent. All other ports will
detect VLAN mapping and the DRB will take appropriate action
concerning appointed forwarders, if necessary. However, TRILL IS-IS
frames are still processed regardless of what VLAN they appear to
arrive on.
     If the TRILL frame is a TRILL Data frame, TRILL doesn't care what
VLAN it "arrives on". The Outer.VLAN, just like the outer source and
destination MAC addresses, are just transport artifacts to get the
TRILL Data payload (which starts with the TRILL Header) from one
RBridge to the next. (Also, TRILL unicast and multi-destination Data
forwarding are not affected by appointed forwarders or port
inhibition.)

I hope the above makes things clearer.

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