[rbridge] Consensus Check: Point to Point links

[Joe Touch]

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/9e519f34/signature.bin