[rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
erik.nordmark at sun.com
Wed Oct 18 09:59:02 PDT 2006
Dinesh G Dutt wrote:
> I can see a few other possibilitites for the use of a source Rbridge field.
> - Consider for example, we want to return an error or send a
> notification to the ingress Rbridge from the middle of the network,
> analogous to an ICMP message. With the source RBridge, you know who to
> send it to.
> - It allows hardware-based learning
> - It assists in network trouble-shooting
I'd be interested in understanding the error reporting and
trouble-shooting aspects a bit more.
Link state routing protocols have been used for IP traffic for a long
time, and the operational tools used to not include the ability to tell
the ingress (first) IS-IS/OSPF router something. The error reporting is
just ICMP errors that are sent back to the IP source of the packet, plus
MIBs and the like which allows network managers to observe the routers.
We could choose to just rely on the same approach for RBridges, in which
case an ingress rbridge address isn't required.
Or we could try to come up with different way to trouble-shoot RBridged
networks, but I certainly don't feel I understand what such a solution
would look like. Would it mean we (or IEEE 802) would need to define L2
error messages that can be sent back similar in spirit to ICMP? Would we
need to invent a L2 or RBridge "traceroute" application?
Given that both IP networks using link-state routing protocols, and IEEE
802.1D networks get away without reporting errors to the ingress, I
think we need to understand this space quite a bit more before embarking
down that path.
More information about the rbridge