[rbridge] Consensus Check: Point to Point links

touch at ISI.EDU (Joe Touch) Sat, 06 October 2007 00:22 UTC

From: "touch at ISI.EDU"
Date: Fri, 05 Oct 2007 17:22:43 -0700
Subject: [rbridge] Consensus Check: Point to Point links
In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA202343EFA@nuova-ex1.hq.nuovaimpresa.com>
References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA202343EFA@nuova-ex1.hq.nuovaimpresa.com>
Message-ID: <4706D553.9010802@isi.edu>


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.

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

-------------- 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/20071005/8c0b6273/signature-0001.bin