[rbridge] Consensus Check: Point to Point links

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Friday, October 05, 2007 5:23 PM
> To: Silvano Gai
> Cc: Eastlake III Donald-LDE008; Radia Perlman; Rbridge at postel.org
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > If there is a bridge in between two RBridges you need to have a full
> > adjacency table.
> >
> > If the link is point to point, you can save the table.
> 
> If the link is point to point, I still need to know what to send over
> the link, so each side still needs adjacency information.

This is not correct; you need to do a lookup to find the port, that is
it.
Otherwise you need to do a lookup to find the MAC address, rewrite the
MAC address and then another lookup to find the port.

-- Silvano

> 
> > When the standard will be done, 40 and 100 Gb/s links will start to
be
> > used.
> > On these links saving the adjacency table is a big deal.
> 
> And when those links are defined, such pt-pt links can be usefully
> defined within the IEEE.
> 
> > It is not only the silicon cost, but also the memory bandwidth.
> >
> > I don't see the additional complexity of a statement that says:
> > "on point-to-point link the MAC address xxxxxxxxx can be used as a
> > destination MAC".
> 
> I see absolutely no need for this group to make that recommendation.
> 
> Joe
> 
> >
> > -- Silvano
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:touch at ISI.EDU]
> >> Sent: Friday, October 05, 2007 12:05 AM
> >> To: Silvano Gai
> >> Cc: Eastlake III Donald-LDE008; Radia Perlman; Rbridge at postel.org
> >> Subject: Re: [rbridge] Consensus Check: Point to Point links
> >>
> >> I do not understand the need to avoid a single entry per link. This
is
> >> hyperoptimization at the expense of complexity, and isn't useful.
> >>
> >> Joe
> >>
> >> Silvano Gai wrote:
> >>> 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
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> rbridge at postel.org
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >