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

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Fri, 23 Jun 2006 15:33:20 -0700

Hannes -

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Friday, June 23, 2006 2:06 PM
> To: Les Ginsberg (ginsberg); Stefano Previdi (sprevidi)
> Cc: isis mailing list
> Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft
> available
> 
> 
> 
> Les Ginsberg (ginsberg) wrote:
> > Folks -
> >
> > An update to the IS-IS Multi-instance Multi-topology draft is now
> > available. Here's the URL and the Abstract.
> >
> > http://www.ietf.org/internet-drafts/draft-previdi-isis-mi-mt-01.txt
> >
> >
> > Abstract
> 
> stefano & les,
> 
> some comments and a question from my side:
> 
> comment ad 3.1 Instance Identifier TLV
> 
>    it would be in the good tradition of the isis-wg to
>    make a suggestion of a codepoint for the TLV.
> 

Yes - I agree. I am sure we will get around to it before too long.

> general comment &
> comment ad 3.4.1 MI-ISIS Layer 2 multicast address and
> comment ad 3.4.2 Interoperability using p2p networks
> 
>    this draft is a non-downwards compatible change, from the moment
you
>    add support for multi-instance all nodes in your network need to
> support it.
>

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.

>    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.

> 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...

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

This sounds like a trick question. :-)
Have them share a topology!!

   Les

> /hannes

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

---

From: Hannes Gredler <[email-masked]>
Date: Sat, 24 Jun 2006 02:06:45 +0200

> issues, please point out a specific problem (or problems) that you

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.

> way to allow multiple instances to run on a LAN and be invisible to

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
>>   that does not understand pdu-version 2 will ignore it anyway, which is
>>   IMO a cleaner transition tool.

> 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. -

>> 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