[rbridge] Time for a summary?

Ed Bowen edbowen at us.ibm.com
Fri Oct 20 11:23:43 PDT 2006






All,

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.

Best regards,
Ed

rbridge-bounces at postel.org wrote on 10/20/2006 12:20:59 PM:

> Radia,
>
> I am not the right person for the summary, but let me give you my
> perspective:
>
> It is bits Vs features:
>
> - One group advocates that features have been defined in the TRILL
> charter and in the doc:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-00.txt
> 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:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
> .txt
> 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
> 0.37%.
>
> 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
> days
> > 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
> putting
> > 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
> http://mailman.postel.org/mailman/listinfo/rbridge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20061020/89b6820c/attachment.html


More information about the rbridge mailing list