< draft-ietf-ipngwg-router-renum-09.txt		draft-ietf-ipngwg-router-renum-10.txt >
	IPng Working Group Matt Crawford		IPng Working Group Matt Crawford
	Internet Draft Fermilab		Internet Draft Fermilab
	June 25, 1999		March 10, 2000
	Router Renumbering for IPv6		Router Renumbering for IPv6
	<draft-ietf-ipngwg-router-renum-09.txt>		<draft-ietf-ipngwg-router-renum-10.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026. Internet-Drafts are		all provisions of Section 10 of RFC 2026. Internet-Drafts are
	working documents of the Internet Engineering Task Force (IETF), its		working documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	skipping to change at page 21, line 4 ¶		skipping to change at page 21, line 4 ¶
	may be exploited to permit shared management of a border router, for		may be exploited to permit shared management of a border router, for
	example, or to discard all Router Renumbering traffic arriving over		example, or to discard all Router Renumbering traffic arriving over
	tunnels.		tunnels.
	9. Implementation and Usage Advice for Reliability		9. Implementation and Usage Advice for Reliability
	Users of Router Renumbering will want to be sure that every non-		Users of Router Renumbering will want to be sure that every non-
	trivial message reaches every intended router. Well-considered		trivial message reaches every intended router. Well-considered
	exploitation of Router Renumbering's retransmission and response-		exploitation of Router Renumbering's retransmission and response-
	directing features should make that goal achievable with high		directing features should make that goal achievable with high
	confidence in a modestly reliable network.		confidence even in a minimally reliable network.
	In one set of cases, probably the majority, the network management		In one set of cases, probably the majority, the network management
	station will know the complete set of routers under its control.		station will know the complete set of routers under its control.
	Commands can be retransmitted, with the "R" (Reply-requested) flag		Commands can be retransmitted, with the "R" (Reply-requested) flag
	set in the RR header, until Results have been collected from all		set in the RR header, until Results have been collected from all
	routers. If unicast Security Associations (or the means for		routers. If unicast Security Associations (or the means for
	creating them) are available, the management station may switch from		creating them) are available, the management station may switch from
	multicast to unicast transmission when the number of routers still		multicast to unicast transmission when the number of routers still
	unheard-from is suitably small.		unheard-from is suitably small.
	skipping to change at page 22, line 43 ¶		skipping to change at page 22, line 43 ¶
	Pp A presumptive, pessimistic initial estimate of the lower		Pp A presumptive, pessimistic initial estimate of the lower
	bound of the round-trip probability, P, to prevent early		bound of the round-trip probability, P, to prevent early
	termination. (See below.) Default 0.75.		termination. (See below.) Default 0.75.
	Ti The initial time between Command retransmissions. Default 4		Ti The initial time between Command retransmissions. Default 4
	seconds. MaxDelay milliseconds (see section 4.1) must be		seconds. MaxDelay milliseconds (see section 4.1) must be
	added to the retransmission timer. Knowledge of the		added to the retransmission timer. Knowledge of the
	routers' processing time for RR Commands may influence the		routers' processing time for RR Commands may influence the
	setting of Ti. Ti+MaxDelay is also the minimum time the		setting of Ti. Ti+MaxDelay is also the minimum time the
	management must wait for Results after each transmission		management station must wait for Results after each
	before computing a new confidence level. The phrase "end of		transmission before computing a new confidence level. The
	the Nth interval" means a time Ti+MaxDelay after the Nth		phrase "end of the Nth interval" means a time Ti+MaxDelay
	transmission of a Command.		after the Nth transmission of a Command.
	Tu The upper bound on the period between Command		Tu The upper bound on the period between Command
	retransmissions. Default 512 seconds.		retransmissions. Default 512 seconds.
	The following variables, some a function of the retransmission		The following variables, some a function of the retransmission
	counter N, are used in the next section.		counter N, are used in the next section.
	T(N) The time between Command transmissions N and N+1 is V*T(N) +		T(N) The time between Command transmissions N and N+1 is V*T(N) +
	MaxDelay, where V is random and roughly uniform in the range		MaxDelay, where V is random and roughly uniform in the range
	[0.75, 1.0]. T(1) = Ti and for N > 1, T(N) = min(2*T(N-1),		[0.75, 1.0]. T(1) = Ti and for N > 1, T(N) = min(2*T(N-1),
	skipping to change at page 28, line 21 ¶		skipping to change at page 28, line 21 ¶
	expertise. Relentless browbeating by various IESG members may have		expertise. Relentless browbeating by various IESG members may have
	improved the final quality of this specification.		improved the final quality of this specification.
	12. References		12. References
	[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing		[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 2373.		Architecture", RFC 2373.
	[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402.		[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402.
	[ANM] Isaacson, E. and H. B. Keller, "Analysis of Numerical Methods",		[ANM] Isaacson, E. and H. B. Keller, "Analysis of Numerical
	John Wiley & Sons, New York, 1966.		Methods", John Wiley & Sons, New York, 1966.
	[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload		[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
	(ESP)", RFC 2406.		(ESP)", RFC 2406.
	[IANACON] Narten, T. and H. T. Alvestrand, "Guidelines for Writing		[IANACON] Narten, T. and H. T. Alvestrand, "Guidelines for Writing
	an IANA Considerations Section in RFCs", RFC 2434.		an IANA Considerations Section in RFCs", RFC 2434.
	[ICMPV6] Conta, A. and S. Deering, "Internet Control Message		[ICMPV6] Conta, A. and S. Deering, "Internet Control Message
	Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)",		Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)",
	RFC 2460.		RFC 2460.
End of changes. 6 change blocks.
	9 lines changed or deleted		10 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/