Subject: Re: [rbridge] A question about the Rbridge ID

From: Xu Xiaohu <[email-masked]>
Date: Thu, 02 Sep 2010 11:50:59 +0800

Hi Donald,

Does the TRILL multicast forwarding table including only VLAN-based pruning
filters on each TRANSIT RB look like this:

  +---------+--------+-----------+
  |Tree ID  |VLAN ID |Adacencies |
  +---------+--------+-----------+
  |         |   *    | a,b,c     |
  |         +--------+-----------+
  |         |   1    | a,b,      |
  | RB1     +--------+-----------+
  |         |   2    | a,c,      |
  |         +--------+-----------+
  |         |   ...  |   ...     |
  |         +--------+-----------+
  |         |  4095  | a,b,c     |
  +---------+--------+-----------+
  |                              |
  | ...                          |
  +---------+--------+-----------+
  |         |   *    | a,b,c,d   |
  |         +--------+-----------+
  |         |   1    | a,b,d     |
  | RBn     +--------+-----------+
  |         |   2    | a,c,d     |
  |         +--------+-----------+
  |         |   ...  |   ...     |
  |         +--------+-----------+
  |         |  4095  | a,b,c     |
  +---------+--------+-----------+

If multicast MAC addresses are also included in the TRILL multicast
forwarding table as pruning filters, does the forwarding table entries for a
given tree (e.g., RBk) on each TRANSIT RB look like this:

  +---------+-------+-------------+-----------+
  |Tree ID  |VLAN ID|   M-MAC     |Adacencies |
  +---------+-------+-------------+-----------+
  |         |   *   |     *       | a,b,c,   |
  |         +-------+-------------+-----------+
  |         |       |     *       | a,b,      |
  |         |       +-------------+-----------+
  |         |   1   |    MAC1     | a,b       |
  |         |       +-------------+-----------+
  |         |       |    ...      | ...       |
  |         |       +-------------+-----------+
  |         |       |    MACi     | a,        |
  |         +-------+-------------+-----------+
  |  RBk    |       |                         |
  |         |  ...  |   ...                   |
  |         |       |                         |
  |         |       |                         |
  |         +-------+-------------+-----------+
  |         |       |     *       | a,b,c     |
  |         |       +-------------+-----------+
  |         | 4095  |    MAC1     | a,b       |
  |         |       +-------------+-----------+
  |         |       |    ...      | ...       |
  |         |       +-------------+-----------+
  |         |       |    MACj     | a,c       |
  +---------+-------+-------------+-----------+

If so, regardless of the computation burden for many SPF trees on each
TRANSIT RB, do you believe the forwarding table itself is quite simple?

Best wishes,
Xiaohu

> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:[email-masked]]
> 发送时间: 2010年9月2日 10:22
> 收件人: 'Donald Eastlake'
> 抄送: [email-masked]'; [email-masked]'
> 主题: re: [rbridge] A question about the Rbridge ID
> 
> Hi Donald,
> 
> > -----邮件原件-----
> > 发件人: Donald Eastlake [mailto:[email-masked]]
> > 发送时间: 2010年9月2日 0:19
> > 收件人: Xu Xiaohu
> > 抄送: [email-masked]; [email-masked]
> > 主题: Re: [rbridge] A question about the Rbridge ID
> >
> > Hi,
> >
> > On Wed, Sep 1, 2010 at 4:52 AM, Xu Xiaohu <[email-masked]> wrote:
> > > Hi all
> > >
> > > Another possible side-effect of using nicknames rather than IP
addresses
> as
> > trill rbridge IDs and accordingly using trill header rather than IP
header
> is
> > making the multicast distribution in trill network unscalable, complex
and
> > inefficient.
> >
> > I think multi-destination frame distribution in TRILL is quite simple
> > and efficient.
> >
> > > First, if there are 4096 VLANs in a trill network and each VLAN is
mapped
> > to a distinct tree, each transit rbridge would have to calculate 4096
SPF
> trees,
> > and any certain topology change may cause all these 4096 SPF trees to be
> > recalculated. Is this usage scalable from the perspective of the control
> plane?
> >
> > First of all, the default number of trees is one. Most people believe
> > that a small number tree will be enough even for very big networks.
> 
> IMHO, whether or not it is enough depends on many factors, e.g., network
scale,
> network topology and location distribution of multicast senders/receivers
etc.
> 
> Take the following simplest topology as an example, if RB1 is elected as
the
> root of the only tree on the trill network, RB2 and RB3 each will
calculate
> a SPF tree with RB1 as root, as a result, the link between RB2 and RB3
will
> be blocked in the only distribution tree. Assume the multicast sender is
> attached to RB2 while the only multicast receiver is attached to RB3, the
> multicast traffic would have to be relayed by the root RB1. It is not
optimal
> than the tree which is rooted at the ingress RB. If there were multiple
ingress
> RBs in a large trill network, how could you ensure that the root of the
only
> tree is close to every ingress RB?
> 
>              +-----+
>              | RB1 |
>              *-----*
>             /       \
>            /         \
>           /           \
>          /             \
>         /               \
>        /                 \
>      +/----+          +---\-+
>      | RB2 +----------+ RB3 |
>      +-----+          +-----+
> 
> 
> > Second, VLANs are not mapped to trees in TRILL. Every tree carries
> > traffic for all VLANs. There is no facility in the TRILL standard to
> > restrict the VLANs of traffic using a multi-destinaiton frame
> > distribution tree. It is the ingress RBridge that makes the decision.
> 
> Yes, here I just list two BASIC possible options for building optimal
multicast
> distribution trees; one is to build a tree per VLAN (even per
<VLAN+multicast
> address> pair) which only carries traffic for the dedicated VLAN, the
other
> is to build a tree per edge RB which carries traffic for all VLANs. In the
former,
> the transit RB would no more need to prune the multicast traffic according
to
> the inner VLAN of the traffic and the set of VLANs reachable downstream
per
> adjacency. In the latter, the multicast traffic is forwarded along the
optimal
> distribution path, but the transit RB would have to prune the multicast
traffic
> according to the inner VLAN of the traffic and the set of VLANs reachable
> downstream per adjacency. Certain topology change will cause each transit
RB
> to update its pruning filters accordingly for each tree.
> 
> Yes, you can choose other variations, e.g., a single tree in a trill
network
> which carries multicast traffic of all VLANs.
> 
> > > Second, if multiple VLANs are associated with a single tree in a trill
> network,
> > each transit rbridge receiving multicast traffic from this tree would
have
> to
> > prune such distribution tree on per-VLAN basis so as to avoid
unnecessary
> > bandwidth waste, e.g., for each adjacency and for each tree, each
transit
> > rbridge has to mark the set of VLANs reachable downstream. Wouldn't this
usage
> > make the hardware multicast forwarding table much complex?
> >
> > As I say, there is no association between VLANs and trees. All trees
> > are usable for all VLANs.
> 
> OK.
> 
> > It is optional feature but a "SHOULD" for a transit RBridge to prune
> > based on VLAN. It is optional feature but a "SHOULD" for a transit
> > RBridge to prune based on destination multicast address. Implementing
> > this pruning for any particular number of VLANs, number of multicast
> > group, and/or number of tree is an engineering problem. No doubt to be
> > able to prune all possible VLANs and a very large number of multicast
> > groups and a very large number of trees would involve some difficulty,
> 
> Agree.
> 
> > depending on what the value of "large" is. but, as I say I don't know
> > of anyone planning to use a large number of multi-destination frame
> > distribution trees. There are a number of techniques available some of
> > which provide tradeoffs between various network metrics.
> 
> Yes, it is a tradeoff.
> 
> > > Third, if an ingress rbridge of a given tree is not close to the root
of
> such
> > tree, the multicast forwarding efficiency of trill network is the same
as
> that
> > of the current STP bridge network, and less efficient than the Source
Path
> Tree
> > (SPT) used in PIM-SM.
> >
> > I don't know what you mean by "forwarding efficiency". The root of a
> > distribution tree could be a leaf node of that tree. The best thing to
> 
> Maybe you wanted to say the ingress RB could be a leaf node of that tree,
right?
> 
> > do depends on your network environment. If you have lots of scattered
> > senders and listeners for multicast frames, optimal distribution in
> > terms of minimal link utilization would requires lots of tree,
> > although the gain in efficiency over a few trees seems small, but
> > above you are complaining about how hard it is to maintain lots of
> > trees. In TRILL, you can specify many or few although, of course, what
> > you can do depends on your RBridge campus size and topology and your
> > switches and what trade off you want between better routing and more
> > rapid re-calculating when there is a topology change. If you have a
> > few very heavy multicast source RBridge, for example, you can, in
> > TRILL, have multiple different shortest-path trees calculated rooted
> > at each, if you network topology provides for that, so you can
> > multi-path multi-destination frames from these heavy sources while
> > still being optimal.
> 
> Agree.
> 
> > > In contrast, if IP routing is used between rbridges, MVPN technology
could
> > be easily inherited into trill. For example, each customer VLAN is
associated
> > with a dedicated provider multicast group address. And the multicast
> > distribution trees on the provider network are built based on the proven
> PIM-SM
> > technology.
> >
> > PIM-SM is clearly less efficient than TRILL in terms of link
> > utilization because frames frequently get unicast across the network
> > and then distributed on a tree. I'm not sure I know enough about the
> > rest of your acronym blizzard to respond properly.
> 
> RPT (RP tree) can be switched automatically to the SPT (Source Path Tree).
In
> particular, if the egress PE knows the addresses of the ingress PEs
belonging
> to the same MVPN, such egress PE could directly use PIM-SSM to construct
the
> SPTs rooted at each ingress PE.
> 
> > I am not impressed now you keep emphasizing how "proven" certain
> > technologies are. TRILL is a new and superior technology not bound to
> > copy existing protocols. I would say that AppleTalk and OSI and ATM
> > and many other protocols are proven technology that is even older and
> > so more "proven" than those you cite. That does not mean we should
> > copy them.
> 
> If the proven technologies are still valuable, we should reuse them rather
than
> spending a lot of time to invent and verify a totally new technology,
unless
> the new technology has many charming advantages over the old ones.
> 
> Best wishes,
> Xiaohu
> 
> > > If I misunderstood it in some ways, please feel free to correct me.
> > >
> > > Best wishes,
> > > Xiaohu
> >
> > Thanks,
> > Donald
> >
> > >> -----邮件原件-----
> > >> 发件人: Xu Xiaohu [mailto:[email-masked]]
> > >> 发送时间: 2010年8月30日 9:12
> > >> 收件人: 'Donald Eastlake'
> > >> 抄送: [email-masked]'; [email-masked]'
> > >> 主题: re: [rbridge] A question about the Rbridge ID
> > >>
> > >> Hi Donald,
> > >>
> > >> > -----邮件原件-----
> > >> > 发件人: [email-masked]
> [mailto:[email-masked]]
> > 代
> > >> 表
> > >> > Donald Eastlake
> > >> > 发送时间: 2010年8月29日 6:00
> > >> > 收件人: Xu Xiaohu
> > >> > 抄送: [email-masked]; [email-masked]
> > >> > 主题: Re: [rbridge] A question about the Rbridge ID
> > >> >
> > >> > Hi Xiaohu,
> > >> >
> > >> > I'll try to give an answer to your questions below:
> > >> >
> > >> > On Fri, Aug 27, 2010 at 9:39 PM, Xu Xiaohu <[email-masked]> wrote:
> > >> > > Hi Radia,
> > >> > >
> > >> > > As stated in RBRIDGE specification:
> > >> > >   "To save room in the TRILL header and simplify forwarding
lookups,
> > a
> > >> > >   dynamic nickname acquisition protocol is run among the RBridges
to
> > >> > >   select 2-octet nicknames for RBridges, unique within the
campus,
> > >> > >   which are an abbreviation for the 6-octet IS-IS system ID of
the
> > >> > >   RBridge.  The 2-octet nicknames are used to specify the ingress
and
> > >> > >   egress RBridges in the TRILL header."
> > >> > >
> > >> > > My question is why not consider to use IP addresses directly as
Rbridge
> > >> > > identifiers. To realize free configuration, these IP addresses
could
> > also
> > >> > be
> > >> > > automatically generated in the similar way as the TRILL nickname
does.
> > >> >
> > >> > An obvious disadvantage is that IP addresses are twice as big as
TRILL
> > >> > nicknames for IPv4 (worse for IPv6 but I can't see why you would
use
> > >> > IPv6). But the main thing is that TRILL has already made its
decision.
> > >> >
> > >> > > Some conceivable benefits of using IP address as Rbridge ID
include:
> > >> > >
> > >> > > 1) The core Rbridge could directly use the proven IP forwarding
chips.
> > >> >
> > >> > There was consideration of using various existing headers (IP,
> > >> > 802.1ah, MPLS) early on in the development of the TRILL standard
but
> > >> > these were all rejected for one reason or another. It is my
> > >> > understanding that leading switching chip companies now all have
TRILL
> > >> > chips so chip availability is not a problem.
> > >>
> > >> Yes, TRILL chips are available. However, the economy of scale for IP
chips
> > is
> > >> not available for TRILL chips.
> > >>
> > >> Thanks for your reply anymore.
> > >>
> > >> Best wishes,
> > >> Xiaohu
> > >>
> > >> > > 2) Matured OAM tools for IP, e.g., PING and Traceroute, can be
used
> > >> > > directly. Or do you have any plan to develop TRILL nickname based
PING
> > or
> > >> > > Traceroute tools?
> > >> >
> > >> > RBridges are designed so that an RBridge level Traceroute could be
> > >> > added fairly easily. There are two drafts that I know of which are
> > >> > being developed for TRILL OAM tools of one sort or another. OAM is
> > >> > listed on the proposed new Charter for the TRILL WG.
> > >> >
> > >> > > 3) Features in the IP header, e.g., QoS, Fragmentation can be
inherited
> > >> > > naturally. For example, there is no need to use complex
technology
> to
> > deal
> > >> > > with large packet as stated in Rbridge specification, "... If
traffic
> > >> > > engineering tools know which links support larger than minimally
> > acceptable
> > >> > > data packet sizes, paths can be computed that can support large
data
> > >> > > packets."
> > >> >
> > >> > Constrained routing does not seem like a complex technology. But,
in
> > >> > any case, people will be expecting Layer 2 QoS, that is frame
> > >> > priority, Data Center Bridging ( see
> > >> > http://tools.ietf.org/html/draft-eastlake-trill-rbridge-dcb-00 ),
and
> > >> > things like that. It was also a goal to be able to incrementally
> > >> > replace 802.1Q customer bridges with RBridges and it seems like a
> > >> > complex design problem to try to do that with IP facilities.
Finally,
> > >> > people engineering Layer 2 networks, particularly in things like
Data
> > >> > Centers, generally have large MTUs, sometimes 9K jumbo frames, so
> > >> > exceeding the MTU is rarely a problem and if it is many people
think
> > >> > the fragmentation is an inefficient solution.
> > >> >
> > >> > > Do you believe saving room in the packet header is a strong
reason
> for
> > >> > > developing a totally new TRILL header, rather than reusing the
proven
> > IP
> > >> > > header for the TRILL Rbridge? Or would you please give some other
reasons
> > >> > > for this option?
> > >> >
> > >> > I would say it doesn't matter any more. The TRILL header has
already
> > >> > been developed, the TRILL base protocol specification is approved
as
> > >> > an IETF standard, hardware has already been developed or adapted
for
> > >> > TRILL, TRILL implementations are far enough along that a publicly
> > >> > announced TRILL interoperability event has been held at UNH IOL and
it
> > >> > looks like a second one will be scheduled early next year. I don't
see
> > >> > any reason for TRILL to change the basic design at this point.
> > >> >
> > >> > > Best wishes,
> > >> > > Xiaohu
> > >> >
> > >> > Thanks,
> > >> > Donald
> > >> >
> > >> > _______________________________________________
> > >> > rbridge mailing list
> > >> > [email-masked]
> > >> > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> > >

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 2 Sep 2010 00:24:03 -0400

I see no reason to believe that any of the alternatives you have
suggested is any better than TRILL when you take into account all of
the factors including tree maintenance, pruning information, reverse
path forwarding check information, link utilization, and header size.

If your table below is supposed to show that handling many trees with
perfect pruning for many VLANs and many multicast groups in a large
network is a hard problem, that is something I agree with.

If you want to find out how people are implementing the TRILL base
protocol standard and what engineering techniques and tradeoffs they
are using, I recommend you speak with those implementors.

Thanks,
Donald

PS: TRILL distribution tree are identified by nickname, not by the
RBridge at which they are rooted. There may be multiple nicknames for
an RBridge. Things can be configured so that tree are calculated for
more than one of these nicknames and those trees will likely be
different.

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 02 Sep 2010 15:08:32 +0800

Hi Donald,

> 发送时间: 2010年9月2日 12:24

> network is a hard problem, that is something I agree with.

This is exactly what the table is supposed to show.

Best wishes,
Xiaohu

> > forwarding table as pruning filters, does the forwarding table entries
for

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 03 Sep 2010 12:19:38 +0800

Hi Donald,

> path forwarding check information, link utilization, and header size.

What does the forwarding table structure in trill look like? Would you
please give me a demo?

Since the set of VLANs reachable downstream for a given adjacency on a
transit RB is relevant to, rather than irrelevant to the particular tree,
separating the pruning filter table (e.g., VLAN reachability for a given
adjacency) from the multicast forwarding table will not save the hardware
table storage room. On the contrary, it will make the database table
unscalable. For example, how much room do you want to set for the field
which stores the set of Layer 2 multicast addresses derived from IP
multicast groups for which there are receivers downstream?  Even for the
field which contains the set of VLANs reachable downstream, do you think it
is a good idea to use a 4096-bit long binary string (e.g., each bit is set
to 1 or 0 to identify whether the corresponding VLAN is reachable or not.)
as a field of the table?

Best wishes,
Xiaohu

for

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 3 Sep 2010 00:53:32 -0400

I have already told you where to get information about what
engineering techniques are being used to implement the TRILL standard
handling of multi-destination frames. For the second time, I recommend
that you contact the many companies that are and will be marketing
TRILL switches, TRILL chip, etc., for the TRILL product design and
TRILL product engineering questions you are asking.

Donald