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

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

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


> -----Original Message-----
> From: Naiming Shen (naiming)
> Sent: Wednesday, September 21, 2011 1:55 PM
> To: Les Ginsberg (ginsberg)
> Cc: isis mailing list
> Subject: Re: [Isis-wg] I-D Action: draft-ietf-isis-reverse-metric-
> 00.txt
> 
> 
> Les,
> 
> 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 -
> 
> 	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
> 
> 
> 
> 		-----Original Message-----
> 
> 
> 		From: Naiming Shen (naiming)
> 
> 
> 		Sent: Wednesday, September 21, 2011 11:32 AM
> 
> 
> 		To: Les Ginsberg (ginsberg)
> 
> 
> 		Cc: isis mailing list
> 
> 
> 		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
> 
> 
> 		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:isis-wg-
> [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, Internet-
> [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
> 
> 
>