Subject: RE: Suggested improvements to the Path-Specific merge rules in dr aft- ietf-mpls-rsvp-lsp-fastreroute-03

From: Nic Neate <[email-masked]>
Date: Mon, 21 Jul 2003 09:48:40 +0100

That sounds fine to me.

Thanks, Nic.

-----Original Message-----
From: Der-Hwa Gan [mailto:[email-masked]]
Sent: Friday, July 18, 2003 8:56 PM
To: Nic Neate
Cc: Ping Pan; [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: Suggested improvements to the Path-Specific merge rules in
dr aft- ietf-mpls-rsvp-lsp-fastreroute-03 

What do you guys think of the following text from Nic? I made a small
adjustment
to part of the sentence (marked by ^^^), but didn't change anything else.
I think the merging rules are identical in semantics to what I last
proposed, even
though the number of rules further reduce by 1.

It is possible to see detours conflict with each other that MP cannot find
a final Path message that satisfy all of them. In that case, the additional
text in rule 3 is necessary, as well as the last paragraph.

In the last paragraph, is it better to send patherr messages and fail the
merging, or simply pick one of the detours and continue the merge? If we
pick continue, some of the detours will provide link protections but
not node protection. Is that acceptable?

Thanks to Nic for pointing out the potential merging problem.
Der-Hwa

     For all the Path messages that share the same outgoing interface and
     next-hop LSR, the MP runs the following procedure to identify a Path
     message to forward downstream.
  
       1. If one or more of the Path messages is for the protected LSP
	  (a protected LSP is one originated from this node, or with 
	  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	  the FAST_REROUTE object, or without the DETOUR object),
	  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          one of these must become the chosen Path message.  There could 
							     ^^^^^^^^^^^
	  be more than one in the case that the protected LSP is
	  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          being rerouted.  In that case it is a local decision to choose 
          which one to forward.  Quit.
  
       2. From the remaining set of detour Path messages, eliminate from
          consideration those that traverse nodes that others want to
          avoid.
  
       3. If several still remain, it is a local decision to choose which
          one to forward.  If none remain, then the MP may try and find a
          new route that does avoid all nodes that all merging detour
          Paths want to avoid and forward a Path message with that ERO.

     Once the final Path message has been identified, the MP MUST start to
     refresh it downstream periodically.  Other LSPs are considered merged
     at this node.  For bandwidth reservation on the outgoing link, any
     merging should be considered to have occured before bandwidth is
     reserved.  Thus, even though Fixed Filter is specified, multiple
     detours and/or their protected LSP which are to be merged due to
     sharing an outgoing interface and next-hop LSR will reserve only
     the bandwidth of the final Path message on that outgoing
     interface.
  
     If no merged Path message can be constructed then the MP SHOULD send
     a PathErr in response to the most recently received detour Path
     message.  If a protected Path is chosen to be forwarded, but it
     traverses nodes that some detours want to avoid, PathErrs should be
     sent in response to those detour Paths which cannot merge.