The MPLS WG Archive

[Der-Hwa Gan <dhg@juniper.net>]

Hi Ping,

> Nic,
> 
> Very sorry about the repeated delay, for I have been overwhelmed by 
> other projects lately.
> 
> 
> Der-Hwa,
> 
> Please see below:
> 
> Der-Hwa Gan wrote:
> >>A.  I believe LSRs will never want to merge multiple Path messages for the
> >>protected LSP.
> >>
> >>The merge rules 3 and 5 in section 7.1.2 ("If only one Path message contains
> >>a FAST_REROUTE object ..." and "If several candidates still remain ...
> >>prefer ones with FAST_REROUTE object") imply that we may be merging multiple
> >>Paths for the protected LSP.  Certainly if an upstream node is changing the
> >>route (doing a slow reroute), or just behaving badly, then we may receive
> >>multiple Paths for the protected LSP, but in both these cases we should
> >>reject all but one before we merge with any other detour Paths.
> >>
> >>Does anyone know of a reason why an LSR may ever want to merge multiple
> >>protected Path messages?
> > 
> > 
> > It is possible that an implementation may want to keep all versions of
> > the protected Path message when LSP rerouting itself. It should be a transient
> > situation, and the situation will resolve itself when some of the Path
> > messages times out, leaving just one Path message as the only viable one.
> >
> 
> Exactly. I thought all copies were needed to handle some corner cases.

This is probably an implementation decision, not mandated by the spec.

> 
> > 
> >> - Modifying the final merge rule as suggested at the top:
> > 
> > 
> > I think the simplified merging rule should work fine, and is easier to
> > read and understand. I don't know what is the opinion of other authors
> > of the draft. Can this change be incorporated, or will this cause
> > any problems? I have to ask because I am not the editor of the draft.
> >
> 
> I have no problem of changing the rule as long as it will work with the 
> existing implementations. My fear is that the changes due to the 
> simplification may cause inter-op problems in the future. If you don't 
> think there is any, please send us the new wording.

If we take a look at rule 2 - 6, all they try to do is to identify the
protected LSP from a set of Path messages that contain all possible mutations
of FAST_REROUTE and/or DETOUR objects. And the rules look confusing
because they assume the worst possible case situations.

     2. If one LSP is originated from this node, this must be
        the final LSP. Quit.

     3. If only one Path message contains FAST_REROUTE object, this
        becomes the chosen Path message. Quit. 

     4. If there are several LSPs, and not all of them have a DETOUR
        object, then eliminate those with DETOUR from consideration.
   
     5. If several candidates remain (that is, there are both detour
        and protected LSPs), prefer the ones with FAST_REROUTE object.
   
     6. If none found, prefer the ones without DETOUR object. If none 
        found, prefer the ones with DETOUR object.

I think some simplification is possible, if we simply suggest the guidelines
(but not the details) of finding the protected LSP. As long as protected LSP(s)
are preferred over detours, there should not be inter-op problems.

     1.  If only one 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) then this 
	 becomes the chosen Path message.  Quit.

     2.  If more than one protected LSPs found, eliminate detours (those
	 with the DETOUR object) from consideration.

     3.  From the remaining set of Path messages, eliminate from consideration 
	 any that traverse nodes that others want to avoid.
  
     4.  If several still remain, it is a local decision to
         choose which one to forward.


This way, 1 & 2 replace the original rule 2-6. The original rule 1 becomes
3, and the original rule 7 becomes 4.

The benefits are (a) it is more readable, (b) implementations for rule 1&2 can
be quite simple if the worst case situations (suggested in original 2-6) won't
exist in that implementation.

Will this look ok to all?

Thanks,
Der-Hwa


> 
> Thanks!
> 
> - Ping
> 
> > Thanks,
> > Der-Hwa Gan
> > 
>