[rbridge] Consensus Check: Point to Point links

[Silvano Gai]

I agree with Donald on all points.
The saving comes from not having to maintain an adjacency table on high
speed point-to-point links.

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Thursday, October 04, 2007 9:24 PM
> To: Radia Perlman
> Cc: Rbridge at postel.org
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> Hi Radia,
> 
> See below at @@@
> 
> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> Sent: Thursday, October 04, 2007 11:51 AM
> To: Eastlake III Donald-LDE008
> Cc: Rbridge at postel.org
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> Personally, I need a reminder of what we are trying to accomplish with
> this before I can have
> any opinion.
> 
> a) Is omitting the outer VLAN tag to save space?
> 
> @@@ Yes. The outer VLAN tag does nothing for you on a point-to-point
> link.
> 
> b) Why put in anything for destination address other than the MAC
> address of the next hop
> RBridge, or put in anything into the source address other than your
own
> MAC address?
> It won't save space. So what does it gain?
> 
> @@@ While no one has given a really crisp response to that question,
it
> is my impression that some believe it will make it possible to produce
> simpler, less expensive, or more efficient hardware for this case.
> 
> c) Is there any danger if an RBridge is confused about whether this is
a
> 
> pt-to-pt link or not?
> 
> @@@ I think there might be. And because of this and the extreme
> commonness of the point-to-point case, it may be reasonable to
consider
> this in designing TRILL. For example, if a fixed MAC address were used
> (such as the unicast version of the All-Rbridges multicast address
(just
> turn off the group bit)), then an interface receiving a frame with
that
> source address would know there was a sender on the link who believes
> the link was point-to-point. If the receiver knows it is not
> point-to-point or is unwilling to handle such frames, it could take
> appropriate action. Also, Rbridge would know to never bother
"learning"
> the location of that MAC address.
> 
> @@@ Thanks,
> @@@ Donald
> 
> I can see the advantage of omitting the entire outer header if it is
> somehow absolutely
> known this is a pt-to-pt link, and both ends of the link understand
> this. But that isn't what's
> being proposed here. It seems to be only omitting the VLAN tag, and
> allowing insertion of
> random addresses into the source and destination fields in the outer
> header, if I'm reading
> it correctly.
> 
> So anyway, clarification at this point would certainly help me.
> 
> 
> Eastlake III Donald-LDE008 wrote:
> > This is a check via the mailing list to confirm or refute an
apparent
> > consensus from the minutes of the Chicago meeting for a change from
> > protocol draft -05:
> >
> >    If it is known that a link is a point to point link between two
> >    RBridges, then the outer header, if it is an Ethernet header, can
> >    have any source and/or destination addresses, those addresses
will
> >    be ignored on receipt, and the outer VLAN tag can be omitted.
> >
> > If no particular controversy arises over this in the next two weeks,
> we
> > will declare it to be the working group consensus.
> >
> > Thanks,
> > Donald & Erik
> >
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge