Re: Update to Multi-instance Multi-Topology Draft available

Les Ginsberg (ginsberg) wrote:

> We gave a lot of thought to backwards compatibility - and discussed
> those issues in the draft. If you are not convinced we considered all
> issues, please point out a specific problem (or problems) that you
> believe we overlooked.

i don't think the restrictions on p2p interfaces will practically
work. - there is all sort of real-world strangeness (reconfig, APS)
that could break this. it is easy to makeup a series of events
where e.g. a LSP from a non-zero instance could end-up in instance 0.

>>   we should not use subnet dependend fields (like MAC adresses)
>>   to control the versioning.
> 
> 
> That isn't what we are doing. We use a different MAC address to insure
> that legacy implementations won't see the PDUs they cannot correctly
> process. The protocol behavior hasn't changed at all - but we do need a
> way to allow multiple instances to run on a LAN and be invisible to
> legacy implementations.

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 

>>since this is a essentially a redefinition of
>>   all known TLVs [which are from now on now keyed by the instance-id]
>>   have you thought about using a different PDU version in the IS-IS
>>   common header ?
>>
>>   suggestion:
>>      pdu-version 1 would be used for topology 0 [fully downwards
>>                    compatible] and
>>      pdu-version 2 would be used for the per-instance-keyed
>>                    topologies.
>> 
>>   all PDU type and TLV allocations stay as-is.
>>
>>   that way you rule out any subnet specific dependencies and any node
>>   that does not understand pdu-version 2 will ignore it anyway, which is
>>   IMO a cleaner transition tool.

> One of the wonderful things about IS-IS is that it has survived for a
> long time now and has been extended in many ways without need for a new
> protocol version. Such robustness is to be respected and not discarded
> lightly. Spinning a new version is a major step and one which the
> community has thus far consciously avoided - with good reason I think.
> I see nothing in the proposal which suggests this is a desirable
> approach, let alone necessary. But, I'll keep listening...

TLVs are fine for doing incremental changes - but what you are suggesting
here is to change the semantics of every TLV ever defined (which is to
be keyed by the instance-id) - if you want to do that in a clean way
then you need IMO redefine all TLVs (undesirable) or bump the pdu version
field. -

>>finally a question: how would i link nodes between different
>> topologies if i wanted to do so ?

> This sounds like a trick question. 

oh it isn't - i just wanted to check if there is a way to keep seperate
topologies and still have them connected on a choke point.

---

another question which i don't really understand:

what problem does MI solve that cannot be solved using MT ?
(apart from the 12-Bit vs. 16-Bit Topology/Instance space
difference).

/hannes