Subject: RE: [Isis-wg] Update to Multi-instance Multi-Topology Draft available

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Tue, 27 Jun 2006 06:12:18 -0700

Hannes -

You raise some good points which we have been discussing.
Before providing a more complete response, I wanted to get clarification
on one particular point.

You said:

> there is an underlying assumption that implementations actually parse
> the dest-MAC adress for sanitizing the PDU. if memory serves me
correct
> then iso10589 does not contain a sanity check rule that requires
> to check the destination-MAC adress against the configured Level.
> 
> in addition i know of at least two widely deployed implementations
that
> do not do, or did not do this ;-)
> 

The L3 interface to the subnetwork layer for a LAN typically calls for
the L3 layer to register multicast addresses of interest. In the case of
IS-IS, it would register some subset of (AllL1IS, AllL2IS, AllIS)
depending on what levels it supports and whether it also supports ES-IS.
Multicast address filtering would then be done by the subnetwork layer
through some combination of hardware filtering and software filtering.

This filtering is necessary for two reasons:

1)Without it, L3 would be deluged with irrelevant multicast PDUs
2)As the subnetwork layer typically supports multiple L3 clients, it
must demultiplex the multicast PDUs of interest and direct them to the
interested clients

If one were to examine the IS-IS code in a given implementation which is
processing incoming PDUs on a LAN, I would not be surprised at all to
discover that there is no MAC destination address checking in that code.
But that omission is not of significance to the proposed MI extensions
so long as the filtering I describe above is being performed at a lower
layer.

If however, there is no multicast address filtering (or imperfect
filtering) being performed at the subnetwork layer, then this is of
significance to the proposed extensions. However, the absence of such
filtering would require such an implementation to spend a lot of time at
L3 discarding irrelevant PDUs - and therefore seems highly unlikely.

In the context of my remarks, could you please clarify exactly what you
believe is and is not being done as regards multicast address filtering
in the implementations with which you are familiar?

I also invite others to comment on the same issue so that we may better
understand the nature of the problems (if any) that the proposed MI
extensions might cause on LANs.

Thanx.

   Les

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 28 Jun 2006 00:28:46 +0200

les,

Les Ginsberg (ginsberg) wrote:
[ ... ]
> L3 discarding irrelevant PDUs - and therefore seems highly unlikely.
[ ... ]
 > in the implementations with which you are familiar?

the way L2-mcast-filtering is implemented today in the kernels that i have seen,
(netbsd to give an example - see http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netiso)
is that the kernel driver has got a wellknown,hardcoded list of
L2 mcast MAC adresses (AllL1IS, AllL2IS, AllIS, AllES) -
as soon you enable AF_ISO on one of its interfaces then you end up getting
the full show. right know there isn't a way for a userland module to
dynamically add or remove an arbitrary MAC address at runtime.

the anticipation of the kernel folks is that PDU can get proper demuxed based
on higher-level information (here the NLPID). with this model no harm
(at best some inefficiency) is caused at higher layers.

when we talk about protocol extensions i really dislike to redo all kernel
APIs for bcast interfaces if the same can get done at a cheaper cost, which
would be to bump the IS-IS PDU version field.

can you give some specific reason(s) why extending the PDU version
is not a viable choice ?

   to me that seems to be the most prolific solution as there are

   -no assumptions about the L2 filtering model of the underlying kernel
   -it is uniform on ptp and bcast circuits.
   -at no point i need to worry about downwards compatibility
     (v1 = old nodes that don't support per instance TLV keying)
     (v2 = new nodes that do support per instance TLV keying)
   -little changes at the IS-IS pdu-specific input parsers

let me also re-iterate my last question [which seemed to slip through the cracks]
what is it that can be done with MI that cannot be done with MT ?

/hannes