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

[Radia Perlman]

OK. Here's my proposal.

TRILL IS-IS will always be encapsulated in a TRILL header.
That means the outer Ethertype is always="TRILL" for TRILL IS-IS packets
(whether they are LSPs, Hellos, or SNPs).

I propose using a bit in the TRILL header (that would have been "reserved"
to mean "this is a TRILL IS-IS packet".

Is this OK?

Radia




Radia Perlman wrote:
> 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
>
>
>
>
>
>
>
>
>