[rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?

[Radia Perlman]

Now that I'm editing the spec to be real specific here, I need a sanity 
check, or
advice from implementers about what would be most convenient for them.

My assumption is that we are removing the per-VLAN instance of IS-IS 
(which could
be added later on, for the purpose of distributing endnode information 
that is more
securely learned, say through a cryptographically authenticated layer 2 
enrollment
protocol). But we are requiring RBridges to learn (ingress RBridge, 
source MAC address)
from packets they are decapsulating onto their link.

So we just have the core instance of IS-IS. We have to make sure layer 3 
IS-IS
packets (which might also be flowing across the campus between routers) 
don't
get confused with TRILL IS-IS. We also have to have RBridges easily 
distinguish
TRILL IS-IS Hellos and LSPs from ordinary encapsulated data packets.

When a router generates an IS-IS packet, the destination address will be 
"all-level1-routers"
or "all-level-2 routers", or perhaps, a specific router (for instance, 
to send a PSNP).
The way this is recognized as an IS-IS packet is due to the EThertype=IS-IS.

RBridge, I believe, should not treat IS-IS packets differently from any 
other "data"
packets. If it's addressed to "all-level1-routers" or 
"all-level2-routers" it would be
treated like any other multidestination packet, encapsulated, and sent 
along a distribution
tree. If it's unicast, it is treated like any other unicast packet by 
RBridges, assuming
the layer 2 address specified in the destination is known to the ingress 
RBridge.

The question is---how are TRILL IS-IS packets encoded?

Could we get a second Ethertype for this? I'm assuming not...

I'm assuming we just have a single Ethertype for "TRILL-encapsulated". 
So we have
to use that.

We could use a different multicast destination address for 
"all-RBridges-for-IS-IS" vs
"all-RBridges" that is used for multicast data.

Or we could have a bit in the TRILL header saying "this is an IS-IS packet".

We could in theory not use the TRILL header for IS-IS packets, since in 
theory
IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs 
directly over layer 2).
But then we'd need a separate Ethertype.

So...if we are going to use the TRILL header, then how do we not get 
confused
between TRILL IS-IS and layer 3 IS-IS?

I guess we could assume that it's enough to have TRILL IS-IS use "0" as 
the area
address, and use IS-IS as the Ethertype in the inner header. For 
TRILL-encapsulated
packets, we actually could choose some weirdo Ethertype (like 0) in the 
inner header.
But we still need to differentiate TRILL IS-IS from layer 3 IS-IS on the 
first hop.

This is probably something I should ask the IS-IS WG, since it really 
depends on
idiosyncracies of the current IS-IS implementations.

Radia