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

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Tue, 11 Jul 2006 12:12:24 -0700

Hannes -

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Tuesday, July 11, 2006 11:59 AM
> To: Stefano Previdi (sprevidi)
> Cc: isis mailing list; Les Ginsberg (ginsberg)
> Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft
> available
> 
> On Tue, Jul 11, 2006 at 07:21:59PM +0200, stefano previdi wrote:
> [ ... ]
> | the draft explicitly says that a MI-router not seeing
> | the appropriate IID in received  hello packets will not
> | form any adjacency. No bouncing.
> 
> stefano,
> 
> sorry, perhaps i was unclear what concerns me -
> let me illustrate this by an example:
> 
> lets assume we have a MI router talking to a non-MI
> router over a p2p interface. the MI router wants to
> establish adjacencies for instances {0,1}. now the
> non-MI router gets constantly confused by the two different
> sysids and constantly is bouncing the instance 0 adjacency.
> (in fact it cannot proper distinguish between the two instances)

Please reread Section 3.4.2 of the draft. We have taken pains to prevent
such behavior. I agree than any proposal that introduced the possibility
of adjacency flapping is not acceptable - we have not done so.

> 
> | Les' proposal looks good to me as using different SysIDs
> | fix the misconfig issue you raised.
> 
> the draft would need a safety belt way such that
> non-0 instance PDUs are silently ignored by non-MI
> implementations. dealing with misconfigs at the level
> of adjacency FSM is already too late and one instance
> may impact the other ...

On P2P we make sure we do not send non-zero PDUs to a legacy system.
Om LANs we use the different mcast addresses so legacy routers do not
see the non-zero PDUs.

For the corner case on P2P when for a brief period (due to APS
switchover or some other event which changes the wiring on the fly) we
require different system IDs for the non-zero instance to make sure any
non-zero LSP which might be "leaked" into a legacy router in such a case
is not used for forwarding.

Note that in such a case as soon as the MI capable router receives a
legacy IIH from the neighbor it will both tear down any existing
adjacency on that interface AND subsequently only send instance zero
PDUS on that interface - so the window during which a non-zero LSP might
be sent is brief - and because of the different system ID it does not
affect routing/forwarding in the instance 0 topology.

   Les

> /hannes

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

---

From: Hannes Gredler <[email-masked]>
Date: Sun, 16 Jul 2006 14:47:16 +0200

les,

tx for your responses - see comments inline:

> is not used for forwarding.

lets say we have massive flooding in instance #1 plus an APS event.
then we end up getting a lot of instance #1 LSPs getting installed
in instance zero LSDB, which (as you have pointed out correct)
will be recognized as "disconnected" during SPF computation
and not consume any forwarding state. however it will consume LSDB storage
space and more worse cause confusion on the network operator side,
as you have "zombie" LSPs from another instance that potentially
may hang around for more than 18 hours.

i know a lot of customers who still have heavy-APS deployments and that
artifact of MI is not nice and IHMO should be avoided.

> affect routing/forwarding in the instance 0 topology.

there is a window of opportunity [between an APS switchover and until the
next regular hello is sent] that some LSPs may slip through and unless
you choose a dead-sure way of encoding MI extensions for leagcy systems.

-----

some comment also to the pdu-version 2 usage. - since its nearly the same
set of people that drive IS-IS protocol evolution both in the ITU and IETF
what is the practical hazzle of just adding a note like "because of the non-incremental
nature of the MI extension we demand use of the IS-IS PDU version field codepoint 2"
in the draft text and send a note to the ITU liason ? -

allocating two well-known functional MAC adresses requires a level of coordination
between two standard-bodies as well.

/hannes