[rbridge] Can someone explain Multi-Topology...its purpose, use, etc?
zhangmingui at huawei.com
Sun Mar 4 18:05:50 PST 2012
Multi-Topology (MT) provides physical separation of TRILL traffic. Similar as the MT in layer3, it can be used to achieve a more load-balanced TRILL campus than ECMP; If MTs are set up intentionally (e.g., disjoint MTs), it can be used to realize fast rerouting under failures. But there are some differences between the layer2 MT and layer3 MT. For example, the use of layer2 MT further confines the broadcast domain besides VLAN; The MAC sharing between different topologies is a new topic. The MAC sharing among different topologies future pertain to the asymmetric use of MTs.
One usage of MT I want to add into the discussion is to use MT to distinguish the traffic flow ingressed/egressed by multi-homing members. In this way, we can get rid of the RPFC issue caused by active-active multi-homing. For more information, one can read the draft, http://tools.ietf.org/html/draft-zhang-trill-multi-topo-rpfc-00.
> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Radia Perlman
> Sent: Friday, March 02, 2012 12:05 PM
> To: rbridge at postel.org
> Subject: [rbridge] Can someone explain Multi-Topology...its purpose, use,
> I understand the concept of adding per-topology costs to IS-IS, and
> having different forwarding tables computed for each topology.
> However, especially in order to imagine how it might (as claimed)
> solve various problems, I'd like to have people explain the following,
> or any other questions that people might like to toss into the
> discussion. If it will help, I'll try to make a stab at answering my
> own questions.
> 1) What problem was multi-topology intended to solve?
> There are two things I could imagine, or that people have mentioned to
> me. One is having different paths for IPv4 and IPv6, presumably
> because some of the routers only support one or the other, and
> wouldn't be able to know how to forward the other type. (if all
> routers support both, I can't quite imagine why you'd want different
> paths for IPv4 and IPv6. Can anyone explain that?). The other is to
> solve some of the problems addressed by MPLS traffic engineering; to
> have certain paths reserved for certain types of traffic (e.g., voice
> vs data, or reserved paths for some customers who have negotiated an
> I could imagine different paths being useful in TRILL for
> jumbo-frames, but the path could be computed based on the "link MTU
> size" rather than "topology", I'd think, though one could certainly
> create a "topology" that is for jumbo-frames, and report infinite cost
> for links that don't support whatever size "jumbo" is, in that
> 2) How do switches/routers know which topology to use when forwarding a
> I'd think the safest thing would be to have a topology name in the
> LSPs (say "topology 2"), and then have a field in the data packet that
> specifies "topology 2". If there's an indirect way, as in, IPv4 goes
> on topology 1, and IPv6 goes on topology 2, that is individually
> configered at each router, then there is the danger that some router,
> presumably one that supports both IPv4 and IPv6, forwarding it
> according to a different topology than other routers.
> If it's indirect (because there's no room for a "topology" field in a
> data packet, then it would be good to at least have some router inform
> the others about how to map a data packet onto a topology. (based on
> protocol type? TCP port? packet size?...whatever)
> For TRILL, there was one proposal (that I understood), which was to
> allocate some of the nickname bits to indicate "topology". Although I
> understand this one, it makes me nervous because various people have
> been complaining that they see 16 bits for nickname as not enough...so
> if we steal 2 or 3 bits for "topology", that leaves even fewer bits
> for nickname.
> 3) Specifically for TRILL, why would multi-topology be useful?
> rbridge mailing list
> rbridge at postel.org
More information about the rbridge