[rbridge] Time for a summary?

[Silvano Gai]

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Sunday, October 22, 2006 12:02 PM
> To: Silvano Gai
> Cc: Radia Perlman; Gray, Eric; Dino Farinacci (dino);
rbridge at postel.org
> Subject: Re: Time for a summary?
> 
> 
> 
> Silvano Gai wrote:
> > 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.
> 
> You're talking about the total header; the TRILL-specific portion is
the
> shim. Please see Eric's other posts.

The overhead is given by the total header, you don't send the the
TRILL-specific portion only.

> 
> > 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".
> 
> There are two issues that are distinct - one is running over any 802.1
> tunnel; the other are TRILL-specific.
> 
> > 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.
> 
> 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.
> 

If you spend some time trying to understand my drawings in the mail to
Eric you will see that there is no payload realignment in 1Q.

The existing Ethernet HW aligns the payload natively, it does not
realign.

MPLS, 1Q and 1S DO NOT REALLIGN THE PAYLOAD.

-- Silvano