<div dir="ltr">Hi Kris,<br><br><div class="gmail_quote">On Sat, Sep 27, 2008 at 3:10 AM, Kris Price <span dir="ltr"><<a href="mailto:trill@punk.co.nz" target="_blank">trill@punk.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I was recently introduced to RBridges by Radia Perlman's interesting<br>
techtalk at Google. Is there a digest somewhere that explains the<br>
options considered or the iterations it has been through?</blockquote><div><br></div><div>No. The creation of a thorough digest of that type would be an enormous effort, You are welcome to volunteer to try but, of course, you will never get everyone to agree that your digest is accurate or complete.</div>
<div><br></div><div>I would suggest that you look at the IETF Proceedings and the TRILL WG presentations and minutes therein as well as reading the change history in the base protocol document.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It seems (on the face of it) that RBridges may reconnect partitioned<br>
VLANs or allow access to VLANs used for security (rightly or wrongly).</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
E.g. when two RBridges are separated by an Ethernet that has partitioned<br>
VLANs (or some VLANs disallowed on a trunk ports) the RBridges will<br>
complete the link for those VLANs. Do I understand right?<br></blockquote><div> </div><div>Yes, that's more or less correct. RBridges take the default view from 802.1Q where if you followed the default of having most VLANs on most ports dynamically registrable, the same sort of thing would happen via the mandatory to implement VLAN registration protocol.</div>
<div><br></div><div>The way to avoid this in TRILL would have been to add an additional qualifier to the VLAN ID. For example, in effect, adding an additional high order octet. Then if you wanted to have two disjoint islands of VLAN 0x007, you could configure them to have different values for this additional qualifier and be, in effect, VLAN 0x0007 and 0x1007. Then TRILL would know that the islands were really "different" VLANs and not connect them. But after discussion it was decided not to do this.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, I was curious why MPLS wasn't used as the forwarding method..?<br></blockquote><div> </div><div>Why should it have? The starting point for TRILL/RBridges was always to do Layer 2 forwarding based on link state routing as proposed in Radia's original Infocom paper:</div>
<div><a href="http://www.ieee-infocom.org/2004/Papers/26_1.PDF" target="_blank">http://www.ieee-infocom.org/2004/Papers/26_1.PDF</a> <br></div><div>Nowhere in your message do you state any reason why MPLS would be a better idea.</div>
<div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I searched the mailing list, but google stops at 93 posts, and most of<br>
the references I could find mentioning MPLS were about using the header<br>
in some form, not LSPs for forwarding. But if it's feasible to use LSPs<br>
to forward frames. The LSRs would only need to understand encap/decap of<br>
Ethernet frames onto these TRILL LSPs and a new protocol to establish<br>
the LSPs at the same time as distributing the MAC addresses. E.g.<br>
perhaps modified IS-IS as with RBridges. The drawbacks would seem to be<br>
loss of MAC learning. But I'd have thought much of the hardware is<br>
already there to support such forwarding.</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks<br>
Kris<br>
</blockquote></div><br>Thanks,<br clear="all">Donald<br>-- <br>=============================<br> Donald E. Eastlake 3rd +1-508-634-2066 (home)<br> 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:d3e3e3@gmail.com" target="_blank">d3e3e3@gmail.com</a><br>
</div>