The MPLS WG Archive

[Erblichs <erblichs@earthlink.net>]

Hi group,

	Sorry for the LATE comments...

	A . Abstract Nit..
	"in 10s of milliseconds"

	First, is 90ms the best case for a local
	re-route? This seems somewhat long and I missed
	the reasoning why it isn't closer to 1 ms..

	Is the timeframe the amount of time that a LSR
	detects a link-failure? If the link-failure is
	via a IGP OSPF protocol (hello protocol), then its 
	on the order of secs.

	If the two timeframes differ dramaticlly, should
	the more fine graular timeframe be communicated
	and the adj questioned? Else what would be the
	result of this level of time schizophrenia?

	B. 4 . Local Repair technique : 4.1 One-to-one backup

	First.. How do you know if the condition is link-local
	or effecting the entire node?  If it is a link-local
	condition, R3's backup could be R3-R8-R4. Yes???
		FYI: If it isn't a link-local issue, then
		  are all the the LSPs that transit the effected
		  link aware of the node issue? Should they all
		 revert to their backups??


	C. 4.1 One-to-one backup

	This may be extending this somewhat but..

	Why wouldn't/couldn't R1-R6-R7-R8-R9-R5 be a another
	primary established LSP, that is parallelling the R1->R5
	protected LSP?

	Would it save anything if the merge was always at R5
	once we go thru a Rx backup?

	D. 8.2 Handling Failures

	I am trying to determine whether to separate short-term
	link failures and whether their is/ should be any 
	recorvery for these types of failures..

	I am reading that this section assumes temporary
	failures due to the phrase "once the local link has
	recovered". Is this correct?

	Or should it be "If the local link has recovered..."

	"may not accept Path messages" Is this phrase telling
	us that the reliability is a consideration and that
	switching between protected and backup LSPs is not
	wanted?

	However, now I have read that we had detected a
	link failure with or without sending data thru
	a backup, and now might NOT accept the original
	protected LSP? Why wouldn't we want to accept Path
	messages?

	
	E. 8.2 Handling Failures

	"Path and Resv state MUST NOT be cleared"

	Why not?

	 "and PathTear and ResvErr messages MUST NOT be
           sent immediately"

	Why wait and how long to wait?


	-------

	Enough for me..

	Mitchell Erblich

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls