The MPLS WG Archive

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

Hi Nic,

> All,
> 
> This email sets out some suggested improvements to the Path-Specific merge
> rules in section 7.1.2 of draft-ietf-mpls-rsvp-lsp-fastreroute-03.
> 
> The points here are completely distinct from last year's discussion about
> weaknesses in the Path-Specific method and break-before-make of detours.
> The changes I suggest won't affect interoperability with existing
> implementations.
> 
> In summary, I believe the list of seven merge rules specified in the draft
> should be reduced to the following three:
> 
>    1.  If one of the Path messages is for the protected LSP
>        (and there can be at most one) then this becomes the
>        chosen Path message.  Quit.
> 
>    2.  From the remaining set of detour Path messages,
>        eliminate from consideration any 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.

The proposed text captures the intention of the original merging rules
correctly without over-exposing the technical details. I think it is
a step forward.

> 
> The reasons why I've eliminated the old rules numbers 2, 4, 5 and 6, and
> reordered what was left, are as follows.
> 
> 
> 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.

As you suggested, an LSR may choose to reject all but one, it
is perfectly reasonable too. In this case, rule 3 and 5 become overly
complex and unnecessary.

> 
> 
> B.  I believe that if the MP is on the protected LSP (so it is merging a
> protected Path with one or more detour Paths for the same SESSION,
> SENDER_TEMPLATE, next hop and outgoing interface) then it MUST always
> forward the protected Path message.

I agree.

> 
> An MP on the protected LSP may receive a detour Path which wishes to avoid
> some downstream node on the protected LSP.  In this case merge rule 1

This should not happen. But if it does, the original rule would rule out
the protected LSP from consideration, which is not good.

> ("Eliminate from consideration those that traverse nodes that other Path
> messages want to avoid") will eliminate the protected Path message and
> forward the detour Path.  I think merge rule 3 ("If only one Path message
> contains FAST_REROUTE object, this becomes the chosen Path message") should
> be the first rule.
> 
> Am I right in thinking that this is an error in the draft?

Right, an oversight.

> 
> 
> C.  I can't see the purpose of merge rule 2 "If one LSP is originated from
> this node, this must be the final LSP".

Which means this is the ingress LSR of the LSP. Again, it is just another
way of saying this is the protected LSP itself.

> 
> I think it has the disadvantage that we may break-before-make a detour that
we don't need to.
> 
> For example, if we are merging a new PLR detour Path into an existing
> transit detour Path, then we will swap from the Path we were forwarding to
> the PLR Path message.  The detour will become inactive until the Resv has
> returned from the MP, meaning that a section of the protected LSP is
> unprotected for that period.
> 
> Does anyone know of a reason for this rule, or does everyone agree that it
> could be left as a local implementation decision?
> 
> 
> D.  I think the draft should allow the MP to determine a new ERO to forward
> on a detour Path message.
> 
> The draft doesn't specify what the MP should do if no received Path messages
> are suitable for forwarding (because all are detours and every one traverses
> some node that another wants to avoid).  I think the MP should be allowed to
> try and find a new ERO which does avoid all the nodes which all the merging
> detour Paths require, and forward a detour Path with that ERO.

I didn't think this is possible. All the detours are originated from
some PLR on the protected LSP. Each detour's 'node-to-avoid' information is the
address of immediate downstream node of the PLR. If you have two detours
with different node-to-avoid, then one of node-to-avoid will be closer to the
egress. This detour can safely be the chosen one.


> 
> However, the text of the merge rules implies that the MP must forward one of
> the received Paths (section 7.1.2 paragraph 5 "the MP runs the following
> procedure to select one of them as the Path message to forward downstream").
> Given that the merge point is already discarding all but one of the EROs it
> has received, it does not feel like a significant change to discard them all
> if necessary.
> 
> If merging still fails (because there is no possible route which satisfies
> all the merging detour Paths) then the draft should specify a course of
> action.   I recommend bouncing the most recently received detour Path with a
> PathErr.
> 
> I suggest the following.
> 
>  - Modifying the text from section 7.1.2 paragraph 5 quoted 
>    above to read "the MP runs the following procedure to 
>    identify a Path message to forward downstream".

Ok.

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

Thanks,
Der-Hwa Gan

>    "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."
> 
>  - Adding the following paragraph to the end of section 7.1.2:
>    "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."
> 
> Is there a reason why the MP should not be allowed to determine a new ERO?
> 
> 
> Please can you let me know if you agree with these proposed changes to the
> draft.
> 
> Many thanks,
> 
> Nic
> 
> 
> --
> Nic Neate
> Network Protocols Group
> Data Connection Ltd
> Tel: +44 20 8366 1177
> Fax: +44 20 8363 1468
> <mailto:nhn@dataconnection.com> 
> Web: <http://www.dataconnection.com>
> 
>