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

[Eric Gray (LO/EUS)]

Radia,

	I am not sure how you would specify behaviors that are based
on the assumption that RBridges are specified for a single VLAN -
with separate RBridge instances being used for separate VLANs - if
(as you suggest) there are not separate IS-IS instances per-VLAN.

	How does that work?

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Saturday, May 19, 2007 12:08 AM
> To: Rbridge at postel.org
> Subject: [rbridge] How is an IS-IS packet differentiated from 
> layer 3 IS-IS, and TRILL-encapsulated data packets?
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>