[rbridge] Updated charter
michsmit at cisco.com
Tue Feb 1 17:50:49 PST 2005
> From: Erik Nordmark
> Joe Touch wrote:
> > While I cannot argue with the motivation, I don't think this is a
> > place where we can "eat our cake and have it too". IMO, briding
> > dissimilar MTUs might be possible, but bridging different
> L2 address
> > spaces implies a common address space, which means
> something very much
> > like IP (with all the warts noted above).
> > FWIW, if we end up peeking into L3 to get this done, then
> we ought to
> > call it a router and be done with it.
> The charter calls it neither a router nor a bridge, but a hybrid.
> The solutions that have been discussed will replace the L2
> headers (at least in some cases, and encapsulate in another
> L2 header in some cases), and not decrement the L3 TTL, which
> is different than a bridge (which doesn't replace the L2
> header) and a router (which decrements TTL).
Some specific examples may help clarify, but the above statement sounds like
the traditional bridge of yore i.e. bridges with ethernet and token ring
interfaces that swap MAC headers to the appropriate canonical format and
encapsulating bridging packets over ATM and Frame Relay using RFC1483 and
> Is there a problem with the devices being hybrids?
> They will preserve the behavior that an IP packet injected at
> one end of
> the link will appear unmodified at the other end.
> > Optimizing is one thing, but talking about specifics (involving
> > flooding) or not is where the charter is getting a bit overspecific.
> Ack. Let me see what additional comments Margaret receives
> from the IESG
> and IAB.
> > As to the last bullet, see RFC1812, which IMO provides
> exactly the L3
> > operations that interconnect disparate L2s.
> >> FYI: Some more IAB/IESG comments have come in asking for more
> >> clarifications on the relationship between this WG and the routing
> >> protocol WG(s), so we will most likely need more detail on
> that front
> >> in the charter.
> > Agreed. This doesn't appear to discuss the encapsulation of routing
> > within the rbridge - that it is necessarily opaque to other routing
> > protocols, e.g., BGP in ways unlike other routing protocols.
> Do you mean opaque to the routing protocol used to carry IP
> reachability? (where the ipvlx routing protocol carries L2 address
> Or something different?
> > Concrete list of work items, agreed.
> > Concrete list of approaches to those work items is the task
> of the WG, IMO.
> I'll make another pass over the charter and hopefully fix this.
> rbridge mailing list
> rbridge at postel.org
More information about the rbridge