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

Sun May 20 09:05:41 PDT 2007

Radia, Donald,

from an implementation perspective the less fields you have to test, the easier it is. 

The main problem is to be able to determine in HW, at the port level, if a frame must be forwarded, dropped or redirected to the RBridge CPU.

In bridges it is very easy, BPDUs have a reserved MAC address, bridge ports have few registers that can be loaded with MAC addresses that allows frame to go through blocked port (remember that BPDUs MUST be received even if the port is blocked).

In RBridges a port may be DR blocked. On a DR blocked port we must still receive BPDUs, RBridge IS-IS frames and TRILL encapsulated frames, but we must drop data frames including IS-IS frames used by non-TRILL protocols.

Distinguishing IS-IS used for TRILL from IS-IS used for other protocols is the tricky part.

Donald suggest using a reserved MAC addess, that would be ideal from an implementation perspective, but Radia replies that a PSNP (partial sequence number PDU) may be unicast.

If a MAC address does not work, the next field is the Ethertype. We already know that we will have a pushback in having two Ethertypes for TRILL, so Radia suggests using a single Ethertype and extending it with a rreserved bit. This can be done, as it is also possible to use version 0 for IS-IS and version 1 for TRILL.

I am against redefining the meaning of nicknames or of other fields, since it makes the test much more complex.

The advantage of using a reserved bit is that the frame with Ethertype = TRILL already go through DR blocked ports. The non-TRILL IS-IS frames will have Ethertype = ISIS and will be dropped by DR blocked ports.

All this considered, I am sligtly in favour of using the reserved bit as proposed by Radia.

-- Silvano

________________________________

From: rbridge-bounces at postel.org on behalf of Radia Perlman
Sent: Sat 5/19/2007 11:11 PM
To: Eastlake III Donald-LDE008
Cc: Rbridge at postel.org
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?

Right (what Donald said below).

To summarize -- if we TRILL-encapsulate IS-IS packets, then we have to be
able to notice, based on the TRILL header, that this is a TRILL IS-IS
packet (rather than
an encapsulated layer 3 IS-IS packet).

We might avoid TRILL-encapsulating an IS-IS packet by
using a new multicast address and using the IS-IS Ethertype, but I'm
nervous it might confuse some layer 3 IS-IS implementations. I'm also
worried
that occasionally an IS-IS packet would not be multicast (for instance,
a PSNP
might be unicast).

I'm also worried about the per-VLAN instance of IS-IS. Even if we don't
make advertising endnodes via IS-IS a MUST, or even if we don't mention it
in the first version of the protocol, I'd like to be able to add
advertisement of
"particularly well-learned" endnode addresses via a per-VLAN instance of
IS-IS at
some point in the future, and make the advertisements, as well as the
learning
from them, be a MAY or SHOULD.

So...if we TRILL-encapsulate (in order to use the TRILL Ethertype),
basically all
the fields in the TRILL header are useless. So, we could use a reserved
bit in
the TRILL header to say this
is IS-IS. Or we could reserve a value of nickname (say, nickname=0), and
define
IS-IS to use ingress and egress nickname both=0.

Once we find a way to differentiate a TRILL-encapsulated TRILL-IS-IS from
a TRILL-encapsulated layer 3 IS-IS packet, doing the per-VLAN one won't be
hard. We'd just add a VLAN tag in the "right place".

So---if these are the alternatives, what do people prefer?
TRILL-encapsulate IS-IS packets, using Ethertype=IS-IS in
the inner frame, differentiating TRILL IS-IS from a
TRILL-encapsulated layer 3 IS-IS using either:

a) a reserved bit in the TRILL header
b) reserved nickname values (say ingress nickname = 0)

Radia

Eastlake III Donald-LDE008 wrote:
> Hi Radia,
>
> This proposal seems fine but a few comments, in somewhat miscellaneous
> order:
>
> I believe that multicast addresses are cheap and, if we wanted to, we
> could get any reasonable number; however, multicast frames don't seem to
> me to be the problem. If you receive a frame sent to All Rbridges,
> according to the current protocol draft, it can only have one of two
> Ethertypes, TRILL or IS-IS. And if that Ethertype is IS-IS, then it is
> an IS-IS packet for the TRILL core IS-IS instance. (The qualification
> "core" no longer being necessary with the per-VLAN IS-IS instances
> dropped.)
>
> Layer 3 IS-IS multicast messages would always be sent to a multicast
> address different from All Rbridges.
>
> So it is only unicast IS-IS messages that would be a problem if an
> Rbridge had difficulty telling whether they were for layer-3 or for
> Rbridge IS-IS.
>
> I believe Ethertypes are a much more scarce resource and it is best to
> stick with one, as your proposal does.
>
> A TRILL header with one of the currently reserved bits set would
> certainly serve to mark unicast IS-IS packet intended for TRILL and
> could also be included in the multicast case for greater uniformity and
> added protection against some layer 3 IS-IS router deciding to process
> the frame despite its multicast address. However, most of the fields in
> such a TRILL header are or might be unused. The Rbridges might not yet
> have selected nicknames and in any case the nicknames would not be
> useful, the hop count is not useful, etc.
>
> Thanks,
> Donald
>
> -----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:23 AM
> To: Radia Perlman
> Cc: Rbridge at postel.org
> Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer
> 3 IS-IS, and TRILL-encapsulated data packets?
>
> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>  

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20070520/7c2054f4/attachment-0001.html