[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
- [rbridge] Consensus Check: Point to Point links Eastlake III Donald-LDE008
- [rbridge] Consensus Check: Point to Point links Eric Gray
- [rbridge] Consensus Check: Point to Point links Anoop Ghanwani
- [rbridge] Consensus Check: Point to Point links Joe Touch
- [rbridge] Consensus Check: Point to Point links Caitlin Bestler
- [rbridge] Consensus Check: Point to Point links Eric Gray
- [rbridge] Consensus Check: Point to Point links Eastlake III Donald-LDE008
- [rbridge] Consensus Check: Point to Point links Eastlake III Donald-LDE008
- [rbridge] Consensus Check: Point to Point links Joe Touch
- [rbridge] Consensus Check: Point to Point links Eric Gray
- [rbridge] Consensus Check: Point to Point links Dinesh G Dutt
- [rbridge] Consensus Check: Point to Point links Silvano Gai
- [rbridge] Consensus Check: Point to Point links Joe Touch
- [rbridge] Consensus Check: Point to Point links Silvano Gai
- [rbridge] Consensus Check: Point to Point links Joe Touch
- [rbridge] Consensus Check: Point to Point links Silvano Gai
- [rbridge] Consensus Check: Point to Point links Anoop Ghanwani
- [rbridge] Consensus Check: Point to Point links Joe Touch
- [rbridge] Consensus Check: Point to Point links Silvano Gai
- [rbridge] Consensus Check: Point to Point links Eric Gray
- [rbridge] Consensus Check: Point to Point links Eric Gray
- [rbridge] Consensus Check: Point to Point links Eric Gray
- [rbridge] Consensus Check: Point to Point links Silvano Gai
- [rbridge] Consensus Check: Point to Point links Radia Perlman
- [rbridge] Consensus Check: Point to Point links Caitlin Bestler
- [rbridge] Consensus Check: Point to Point links Anoop Ghanwani
- [rbridge] Consensus Check: Point to Point links Eric Gray
- [rbridge] Consensus Check: Point to Point links Eastlake III Donald-LDE008
- [rbridge] Consensus Check: Point to Point links Eastlake III Donald-LDE008
- [rbridge] Consensus Check: Point to Point links Eastlake III Donald-LDE008
- [rbridge] Consensus Check: Point to Point links Eastlake III Donald-LDE008
- [rbridge] Consensus Check: Point to Point links Silvano Gai
- [rbridge] Consensus Check: Point to Point links Dinesh G Dutt
- [rbridge] Consensus Check: Point to Point links Joe Touch
- [rbridge] Consensus Check: Point to Point links Eastlake III Donald-LDE008
- [rbridge] Consensus Check: Point to Point links Radia Perlman
- [rbridge] Consensus Check: Point to Point links Caitlin Bestler
- [rbridge] Consensus Check: Point to Point links Silvano Gai
- [rbridge] Consensus Check: Point to Point links Joe Touch
- [rbridge] Consensus Check: Point to Point links Joe Touch
- [rbridge] Consensus Check: Point to Point links Silvano Gai
- [rbridge] Consensus Check: Point to Point links Joe Touch
- [rbridge] Consensus Check: Point to Point links Silvano Gai
- [rbridge] Consensus Check: Point to Point links Anoop Ghanwani
- [rbridge] Consensus Check: Point to Point links Joe Touch
- [rbridge] Consensus Check: Point to Point links Eastlake III Donald-LDE008
- [rbridge] Consensus Withdrawn: Point to Point lin… Eastlake III Donald-LDE008