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

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Sun, 16 Jul 2006 16:34:58 -0700

Hannes -

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Sunday, July 16, 2006 5:47 AM
> To: Les Ginsberg (ginsberg)
> Cc: Stefano Previdi (sprevidi); isis mailing list
> Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft
> available
> 
> les,
> 
> tx for your responses - see comments inline:
> 
> Les Ginsberg (ginsberg) wrote:
> >>| 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.
> 
> 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.
> 

In order for "massive flooding" to occur, we would have to have the
following set of circumstances:

a)Router MI-1 has just formed an adjacency with router MI-2 (which has
just started) on circuit MI-1/1 and is in the process of dumping its
Instance #1 LSDB to MI-2.

NOTE: Alternatively, we could hypothesize a massive network disruption
coincidental with Step c below.
 
b)Router L (a legacy router) has an adjacency with some router (identity
unimportant) on circuit L/1.

c)Early in the process of the dump mentioned in "a", an APS event occurs
which causes circuits MI-1/1 and L/1 to be connected.
 
d)A number of seconds remain before either MI-1 or L will transmit an
IIH.

If all of these circumstances occur, then yes - it is possible for a
significant number of Instance #1 LSPs to be added to the LSDB in Router
L - though we both agree that they will be seen as orphans and will not
affect routing/forwarding.

This is still undesirable of course - but there are the following points
to consider:

1)Orphaned LSPs occur in the LSDB in today's world - for example,
whenever a router is removed from the network, it is highly likely that
its old LSPs remain in the network until they age out. In cases of
orderly shutdown, it is possible for a router to purge its LSPs before
"departing", but as a practical matter this often does not occur - and
isn't possible in cases of unexpected failure.

2)The length of the "window of opportunity" above can be shortened
through the use of fast failure detection mechanisms (e.g. BFD)

3)The undesirable consumption of LSDB space can be prevented by the use
of authentication - where the password for Instance #0 is different than
that for non-zero instances.

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

I think our opposing positions on this are clear - so I will not repeat
myself - except to once again invite others to respond.

   Les

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

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