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

From: Nic Neate <[email-masked]>
Date: Wed, 9 Jul 2003 15:34:47 +0100

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:[email-masked]> 
Web: <http://www.dataconnection.com>

---

From: Der-Hwa Gan <[email-masked]>
Date: Thu, 10 Jul 2003 18:01:18 -0700

Hi Nic,

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

> Does anyone know of a reason why an LSR may ever want to merge multiple

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.

> forward the protected Path message.

I agree.

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

> Am I right in thinking that this is an error in the draft?

Right, an oversight.

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

we don't need to.
> 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.

>    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

---

From: Ping Pan <[email-masked]>
Date: Sun, 13 Jul 2003 14:46:13 -0700

Nic,

Very sorry about the repeated delay, for I have been overwhelmed by 
other projects lately.

Der-Hwa,

Please see below:

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

> 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

---

From: Der-Hwa Gan <[email-masked]>
Date: Mon, 14 Jul 2003 12:50:52 -0700

Hi Ping,

> Exactly. I thought all copies were needed to handle some corner cases.

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

> 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

---

From: Ping Pan <[email-masked]>
Date: Tue, 15 Jul 2003 17:41:44 -0400 (EDT)

Der-Hwa,

I think this is a whole lot better. If Nic and Alia have no problem,
let's fold the new rules into the next version.

Thanks!

- Ping

---

From: Alia Atlas <[email-masked]>
Date: Wed, 16 Jul 2003 03:11:22 -0400

>let's fold the new rules into the next version.

Ping & Der-Hwa,

I certainly agree with simplifying the rules to what is logically 
necessary.  This sounds good to me.

Alia