The MPLS WG Archive

[Ping Pan <pingpan@cs.columbia.edu>]

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.

> 
>> - 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.

Thanks!

- Ping

> Thanks,
> Der-Hwa Gan
>