Re: [Isis-wg] I-D Action: draft-ietf-isis-reverse-metric-00.txt

["Les Ginsberg (ginsberg)" <[e-mail]>]

Naiming -

The problem you describe below has been addressed - and more robustly -
by the use of the SA bit as described in RFC 5306.

In the case of a router restart it is the reintroduction of the IS which
needs to be synchronized. As arbitrary configuration changes may have
been made prior to the restart, it is not only transit traffic which we
do not want to be sent prematurely to the restarting router - we also
cannot be certain that leaf node information advertised in the old LSPs
of the restarting system are still valid. We don't want to send any
traffic to the restarting router until LSP DB synchronization (including
flooding of new versions of the restarting router's own LSPs) has been
achieved - which is what the SA bit accomplishes.

The case this draft is aimed at addressing is different than the above
in that the requirement is that a given link be the "path of last resort
bidirectionally" during the maintenance period. Indeed, if the
requirement was simply to prevent use of a given link on the IS
undergoing maintenance there would be no need for this draft at all -
one could either bring down the adjacency or set the SA bit in the
hellos sent on the specified link by the router undergoing maintenance
(note that either of these strategies does not require that the matching
interface on the neighbor be known).

The WG needs to decide if the case being addressed (use link as path of
last resort) justifies the protocol extensions. To be useful, it depends
on having delivery of IS-IS PDUs on the link be unaffected by the
maintenance activity. 

The additional usage you suggest below should not be considered in
evaluating whether draft-ietf-isis-reverse-metric should go forward.

   Les

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Naiming Shen (naiming)
> Sent: Thursday, September 08, 2011 6:56 PM
> To: isis mailing list
> Subject: Re: [Isis-wg] I-D Action: draft-ietf-isis-reverse-metric-
> 00.txt
> 
> 
> This wg draft is just posted with below announcement.
> 
> Note that another good operational usage of this draft is at the
router
> restart with
> 'overload bit' set waiting for bgp convergence or for some other
> reasons.
> Using a simple topology to illustrate the case:
> 
>   B
>  / \
> A   C - E
>  \ /
>   D
> 
> Assume links A-B and B-C has metric of 10, and A-D and D-C has metric
> of 20.
> router B restarts. ISIS on router B sets the 'overload' bit for bgp
> convergence reason.
> 
> (1) Before B comes back up, A sends all the traffic to E through A->D-
> >C to reach bgp
> learned destinations. Assume B comes back in a few minutes.
> 
> (2) When A and B isis adjacency comes up, before B has the chance
> to send out its LSPs(with the 'overload' bit), A may run its SPF. Now
A
> at this time
> may have the older version LSPs(from B's previous life) in its link-
> state database
> and those LSPs don't have the 'overload' bit set. The routes
downloaded
> after
> this SPF run will choose router B as the nexthop for destination for
E.
> But the traffic will be dropped on B due to bgp has not yet converged.
> 
> (3) Then A receives the new LSPs from B, and it re-runs the SPF, it
> again switches the
> traffic away from B towards D.
> 
> (4) Then B's bgp is converged, and B removes 'overload' bit in its
> LSPs, and sends
> them to neighbors. A gets them this time and finally sends traffic
> towards B again.
> 
> This is a timing issue. Between the step (2) and (3) the traffic could
> be briefly
> black-holed. Unlike OSPF, A and B does not have to be completely in
> sync in
> order to bring up the adjacency between them in ISIS. I've observed
> this case
> just recently.
> 
> This draft offers a reasonable solution. While starting up and setting
> the 'overload'
> bit to its LSPs, ISIS can also set a huge reverse metric in its
hellos.
> While A and B can
> still bring up their adjacency, but A will not use B as the nexthop to
> reach E since
> the reverse metric is huge. After the bgp on B is converged, at the
> same time of
> removing the 'overload' bit for LSPs, B removes the reverse metric
also
> in its
> hello packets.
> 
> please comment.
> 
> thanks.
> - Naiming
> 
> On Sep 8, 2011, at 12:50 PM, [e-mail] wrote:
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the IS-IS for IP Internets
> Working Group of the IETF.
> >
> > 	Title           : IS-IS Reverse Metric TLV for Network
> Maintenance Events
> > 	Author(s)       : Naiming Shen
> >                          Tony Li
> >                          Shane Amante
> >                          Mikael Abrahamsson
> > 	Filename        : draft-ietf-isis-reverse-metric-00.txt
> > 	Pages           : 14
> > 	Date            : 2011-07-03
> >
> >   This document describes an improved IS-IS neighbor management
> scheme
> >   which can be used to enhance network performance by allowing
> >   operators to quickly and accurately shift traffic away from a
> point-
> >   to-point or multi-access LAN interface by allowing one IS-IS
router
> >   to signal to a second, adjacent IS-IS neighbor to adjust its IS-IS
> >   metric that should be used to temporarily reach the first IS-IS
> >   router during network maintenance events.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-isis-reverse-metric-
> 00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-isis-reverse-metric-
> 00.txt
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg