The MPLS WG Archive

[Erblichs <erblichs@earthlink.net>]

Sorry,


	Forgot about another item..

	RFC3029 is 
Internet X.509 Public Key Infrastructure
           Data Validation and Certification Server Protocols

	Thus,,,
	

	ZZ.

15. Normative References

    [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
    -- version 1 functional specification," RFC2205, September 1997.

    [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
    tunnels", RFC3029, December 2001.



	Is wrong...

	Mitchell Erblich
	----------------------------

Erblichs wrote:
> 
> 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