[rbridge] Time for a summary?

[Silvano Gai]

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
> 
> >-->
> >
> >