The MPLS WG Archive

[Nic Neate <nhn@dataconnection.com>]

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


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.

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
("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?


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

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.

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

 - Modifying the final merge rule as suggested at the top:
   "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>