Subject: [rbridge] Time for a summary?

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sun, 22 Oct 2006 11:55:03 -0700

Joe, 

Let me first point out the TRILL charter:
"(4) Produce a (set of) TRILL specification(s) for standards track
publication that define(s) what information must be carried in an
encapsulation header for data packets. Although this work will
initially be undertaken only for 802.1-compliant links, it
may later be expanded to non-802.1 links, so the design should be
link-layer agnostic to whatever extent possible."

The spec can define the TRILL header to be 4 bytes, but the overhead
introduced on 802.1-compliant links is 18 bytes.

Therefore, when we compare two solutions from the bandwidth perspective,
we need to say: "the current proposal introduces an overhead of 18
bytes, the new proposal as modified by Dinesh introduces an overhead of
20 bytes".

I also pointed out that 18 is not a multiple of 4 and therefore it
requires the payload to be realigned, while 20 is a multiple of 4, it
does not require realignment, it provides more features, and therefore
IMHO it is superior.

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Saturday, October 21, 2006 10:24 AM
> To: Silvano Gai
> Cc: Radia Perlman; Gray, Eric; Dino Farinacci (dino);
rbridge at postel.org
> Subject: Re: Time for a summary?
> 
> Correction below:
> 
> Silvano Gai wrote:
> > 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
> 
> That doc refers to the shim as defined in:
> draft-bryant-perlman-trill-pwe-encap-00.txt
> 
> The shim - excluding the outer ethernet header - is 4 bytes, not 18.
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Sun, 22 Oct 2006 12:02:29 -0700

> introduced on 802.1-compliant links is 18 bytes.

You're talking about the total header; the TRILL-specific portion is the
shim. Please see Eric's other posts.

> bytes, the new proposal as modified by Dinesh introduces an overhead of

There are two issues that are distinct - one is running over any 802.1
tunnel; the other are TRILL-specific.

> does not require realignment, it provides more features, and therefore

The argument for alignment has not been convincing. 802.1q is a similar
shim header and adds 4 bytes. Tunnels always deal with aligning their
payloads separately; given existing ethernet hardware is capable of
dealing with 14-byte realignment of its payload, we can to.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061022/2f896325/signature.bin