[rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)

[Erik Nordmark]

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

Dinesh,

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.

Regards,
    Erik