[rbridge] Time for a summary?
edbowen at us.ibm.com
Fri Oct 20 11:23:43 PDT 2006
Of the thousand or so customers who are consuming my team's networking
services, I think all would be happy to give up 0.37% of the bandwidth for
these features. I can't imagine a scenario where a customer would say the
0.37% of additional bandwidth is more important. The burst conditions that
actually utilize the last 0.37% of the network are pretty rare.
rbridge-bounces at postel.org wrote on 10/20/2006 12:20:59 PM:
> I am not the right person for the summary, but let me give you my
> It is bits Vs features:
> - One group advocates that features have been defined in the TRILL
> charter and in the doc:
> and that we need to define a TRILL shim that accommodates these features
> using the minimum number of bits.
> - Another group claims that more features are required (e.g.
> Troubleshooting, tracing, efficient multicast, etc.) and that these
> features are worth few extra bytes.
> Let's also use some quantitative analysis. The TRILL Ethernet header
> currently defined in:
> is 18 bytes
> The new proposal as modified by Dinesh Dutt is 20 bytes.
> On an average 512 bytes payload the old proposal has an overhead of
> 3.27% and the new proposal has an overhead of 3.64%, a difference of
> I claim you cannot find a single user that is not willing to spend 0.37%
> of its campus bandwidth to have:
> - more security
> - more troubleshooting (especially under attack)
> - better multicast handling
> - better topology management
> Do you agree?
> -- Silvano
> > -----Original Message-----
> > From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> > Sent: Friday, October 20, 2006 7:07 AM
> > To: Gray, Eric
> > Cc: Silvano Gai; Joe Touch; Dino Farinacci (dino); rbridge at postel.org
> > Subject: Time for a summary?
> > I've been travelling for a few days, and have just enough email access
> > to notice there has been a really
> > high volume of email, which undoubtedly will be hard for me and most
> > others, to catch up on.
> > Can someone who has been following this discussion the last couple
> > post a summary? I think
> > we are arguing over several different potentially added fields:
> > a) F-Tag
> > b) both ingress and egress RBridge
> > c) ingress LID
> > d) egress LID
> > I'd prefer a separate summary of the arguments for and against each of
> > those fields.
> > Whoever is summarizing shouldn't be advocating, but rather just
> > in one message what they understand
> > to be all the arguments presented. I'd prefer no names as in "argument
> > against: extra space in header" rather
> > than "Person X claims it takes extra space".
> > Then people can resume the discussion starting from the summary, and
> > nobody needs to read any
> > of the previous emails.
> > I suppose if nobody does this, I will eventually have some time and
> > attempt it.
> > Thanks,
> > Radia
> > >-->
> > >
> > >
> rbridge mailing list
> rbridge at postel.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rbridge