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

[Naiming Shen <[e-mail]>]

Les,

I understand the RFC 5306, which is the non-stop forwarding scheme
for ISIS. I described here in this context is the case the router restart,
there is no forwarding information, it's a cold boot of the router. There
is no SA bit here.

- Naiming

On Sep 21, 2011, at 12:07 AM, Les Ginsberg (ginsberg) wrote:

> 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