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

From: [email-masked]
Date: Thu, 08 Sep 2011 12:50:17 -0700

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

---

From: Naiming Shen <[email-masked]>
Date: Thu, 8 Sep 2011 18:56:21 -0700

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, [email-masked] wrote:

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Sep 2011 00:07:04 -0700

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: [email-masked] [mailto:[email-masked]] 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
> 
> 
> Note that another good operational usage of this draft is at the
router
> restart with
> (1) Before B comes back up, A sends all the traffic to E through A->D-
> >C to reach bgp
> to send out its LSPs(with the 'overload' bit), A may run its SPF. Now
A
> at this time
> and those LSPs don't have the 'overload' bit set. The routes
downloaded
> after
> bit to its LSPs, ISIS can also set a huge reverse metric in its
hellos.
> While A and B can
> removing the 'overload' bit for LSPs, B removes the reverse metric
also
> in its
> > 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.
> >
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Wed, 21 Sep 2011 11:31:50 -0700

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Sep 2011 13:23:24 -0700

Naiming -

Although RFC 5306 is principally about Graceful Restart, the SA
discussion is specifically applicable to cold start. From Section 3.2.2:

"A router that is starting has no maintained forwarding function
   state.  This may or may not be the first time the router has started.
   If this is not the first time the router has started, copies of LSPs
   generated by this router in its previous incarnation may exist in the
   LSP databases of other routers in the network.  These copies are
   likely to appear "newer" than LSPs initially generated by the
   starting router due to the reinitialization of LSP fragment sequence
   numbers by the starting router.  This may cause temporary blackholes
   to occur until the normal operation of the update process causes the
   starting router to regenerate and flood copies of its own LSPs with
   higher sequence numbers.  The temporary blackholes can be avoided if
   the starting router's neighbors suppress advertising an adjacency to
   the starting router until the starting router has been able to
   propagate newer versions of LSPs generated by previous incarnations."

The term "starting" is defined near the end of Section 2 as:

"The terms "start/starting" are used to refer to a router in which the
   control function has either commenced operations for the first time
   or has resumed operations, but the forwarding functions have not been
   maintained in a prior state."

So SA is targeted at the exact scenario you described in your initial
email.

   Les

> From: Naiming Shen (naiming)
> Sent: Wednesday, September 21, 2011 11:32 AM
> To: Les Ginsberg (ginsberg)
> Cc: isis mailing list
> > The problem you describe below has been addressed - and more
robustly
> -
> >> Assume links A-B and B-C has metric of 10, and A-D and D-C has
> metric
> >> of 20.
> >> (1) Before B comes back up, A sends all the traffic to E through A-
> >D-
> >>> C to reach bgp
> >> may have the older version LSPs(from B's previous life) in its
link-
> >> state database
> >> this SPF run will choose router B as the nexthop for destination
for
> > E.
> >> This is a timing issue. Between the step (2) and (3) the traffic
> could
> >> be briefly
> >> This draft offers a reasonable solution. While starting up and
> setting
> >> the 'overload'
> >> still bring up their adjacency, but A will not use B as the nexthop
> to
> >> reach E since
http://www.ietf.org/internet-drafts/draft-ietf-isis-reverse-metric-

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Sep 2011 14:13:53 -0700

Naiming -

You are not reading the full context. The same paragraph you quote also
says:

" If the adjacency transitions to the "UP"
   state, the new adjacency MUST NOT be advertised until an IIH with the
   SA bit clear has been received."

So SA bit is NOT restricted to existing adjacency cases - and this is
explicitly stated in RFC 5306 as the excerpts I have quoted below
clearly state.

   Les

> Sent: Wednesday, September 21, 2011 1:55 PM
> This is the paragraph in 3.2.2 of the rfc:
> 
> "When a router receives an IIH with the restart TLV having the SA bit
> set, if there exists on this interface an adjacency in state "UP"
> with the same System ID, and in the case of a LAN circuit, with the
> same source LAN address, then the router MUST suppress advertisement
> of the adjacency to the neighbor in its own LSPs. ..."
> In the case I was talking about, the adjacency was long gone. We are
> talking about 10 minutes like of range.
> - Naiming
> 
> 
> On Sep 21, 2011, at 1:23 PM, Les Ginsberg (ginsberg) wrote:
> 
> 
> 	Naiming -
> 
> 	discussion is specifically applicable to cold start. From
Section
> 3.2.2:
> 	  If this is not the first time the router has started, copies
of
> LSPs
> 		Subject: Re: [Isis-wg] I-D Action:
draft-ietf-isis-reverse-
> metric-
> 
> 
> 		00.txt
> 
> 
> 
> 
> 		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
> 			The problem you describe below has been
addressed -
> and more
> 			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
> 			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
> 			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
> 
> 
> 			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
> 			The additional usage you suggest below should
not be
> considered in
> 			evaluating whether
draft-ietf-isis-reverse-metric
> should go forward.
> 				From: [email-masked]
[mailto:isis-wg-
> [email-masked]] On
> 				Subject: Re: [Isis-wg] I-D Action:
draft-ietf-
> isis-reverse-metric-
> 				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.
> 				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
> 				and those LSPs don't have the 'overload'
bit
> set. The routes
> 				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
> 				(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
> 					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
> 					Title           : IS-IS Reverse
Metric
> TLV for Network
> 				Maintenance Events
> 					                       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
> 					Internet-Drafts are also
available by
> anonymous FTP at:
> 					This Internet-Draft can be
retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-
> ietf-isis-reverse-metric-
> 
> 
> 				00.txt
> 
> 
> 
https://www.ietf.org/mailman/listinfo/i-
> d-announce
> 					or
ftp://ftp.ietf.org/ietf/1shadow-
> sites.txt

---

From: Naiming Shen <[email-masked]>
Date: Wed, 21 Sep 2011 14:23:20 -0700

Les,

Then this draft gives an option of last-resort forwarding vs the completely suppression.

- Naiming

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Sep 2011 15:15:14 -0700

Naiming -

> Sent: Wednesday, September 21, 2011 2:23 PM

Yes - we are in agreement. As I stated in my first post, we need to
focus on the new requirements/functionality which
draft-ietf-isis-reverse-metric is attempting to provide - which is the
ability to make a specific link the link of last resort bidirectionally.

My intent in this thread has been to eliminate the cold start use case
you suggested from consideration when evaluating
draft-ietf-isis-reverse-metric. That problem has already been addressed
more robustly by the SA bit - we do not need another solution to that
problem.

   Les