Subject: Re: [rbridge] Questions - VLANs & MPLS

From: Kris Price <[email-masked]>
Date: Sat, 04 Oct 2008 21:25:50 +0800

James Carlson wrote:
> Dinesh G Dutt writes:
>> MPLS format was originally considered and rejected for a few reasons. For 
>> example, we wanted the source and destination RBridge addresses instead of 
>> only the destination RBridge because of the need to support things like 
>> IEEE's congestion management, support troubleshooting tools such as 
>> traceroute and ping within an TRILL cloud etc.
> 
> I think a more important reason for it is that you can't do MAC
> address learning of decapsulated packets unless you know where (what
> encapsulator) they came from.

I wondered about that, but I didn't understand why an RBridge needed to 
do MAC address learning. It seemed that was handled by IS-IS. If I read 
the original paper right that was the intention. (?)

But reading the draft (properly this time) I see MAC learning is now the 
favoured method, with distribution by IS-IS optional. Part of me favours 
this now that I understand it. It means intermediate RBridges don't have 
to maintain information in their FIBs that they're not using.

I guess it was a contentious issue whether learning should've all been 
via a routing protocol, or via learning. Had the former been favoured, 
MPLS label switched paths would've been a feasible forwarding method.

Makes sense now, thanks for your answers :)

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

---

From: "Donald Eastlake" <[email-masked]>
Date: Sat, 4 Oct 2008 15:22:13 -0400

See below...

On Sat, Oct 4, 2008 at 9:25 AM, Kris Price <[email-masked]> wrote:

> I wondered about that, but I didn't understand why an RBridge needed to do
> MAC address learning. It seemed that was handled by IS-IS. If I read the
> original paper right that was the intention. (?)

Yes, that was the original intention. Someone from a routing background
would find that way of doing things to be natural.

> this now that I understand it. It means intermediate RBridges don't have to
> maintain information in their FIBs that they're not using.
>

Yes, those from a bridging background think that learning in the data plane
is much more natural, doesn't overburden the control plane, etc.

However, it was never the case that transit (intermediate) RBridges needed
to maintain link state for end station addresses (unless they have directly
connected end stations in the same VLAN, in which case they really aren't
transit RBridges). The end station address distribution instances are
tunneled through transit RBridges and handled, by transit RBridges, exactly
like data frames. See protocol draft -09 Section 4.2.4.

> I guess it was a contentious issue whether learning should've all been via
> a routing protocol, or via learning. Had the former been favoured, MPLS
> label switched paths would've been a feasible forwarding method.
>

Indeed, this was contentious for a while.
Thanks,
Donald
-- 
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge