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

From: Nic Neate <[email-masked]>
Date: Tue, 15 Jul 2003 13:26:48 +0100

Ping and Der-Hwa,

Thanks for your responses.  You've raised the following points which I'll
give you my input on below.
 - Der-Hwa's suggested merge rules.
 - Concern over interop with existing implementations.
 - Doubt whether failing to merge is possible.
 - Possibility of merging multiple protected Paths during LSP rerouting.

A.  Der-Hwa's suggested merge rules.

My understanding of the draft is that every Path we are merging is either a
protected Path (has a FAST_REROUTE object, or the "Local protection desired"
bit set in SESSION_ATTRIBUTE object) or a detour Path (has a DETOUR object).
This is stated by paragraph 3 of section 7.1.2 (although note that this
misses out the "Local protection desired" flag option):

   For all Path messages that do not have either a FAST_REROUTE or a
   DETOUR object, or the MP is the egress of the LSP, no merging is
   required.  The messages are processed according to [RSVP-TE].

Because that statement is there up front, I think we should just to refer to
"protected Paths" and "detour Paths" in the merge rules.  I've suggested
some new text at the bottom.

B.  Will there be interop problems with existing implementations?

I don't think so.  The Path message forwarded by the new merge rules may
have a different ERO, or be a protected Path instead of a detour.  That will
not matter to the downstream LSR though - it can process it in just the same
way as before.  Existing implementations will only need to be changed if
they wish to avoid the risk of forwarding a detour Path in preference to a
protected one.

C.  Is it possible that no received Path message is suitable for forwarding?

Only in very strained network topologies (but we do have it in system
test!).  Merging can fail either because each detour traverses a node that
another wants to avoid, or because the protected LSP traverses a node that
some detours want to avoid.  I think that these possibilities should be
covered by the draft.

D.  During LSP rerouting, we may need to merge multiple protected Paths.

I agree that this is a possibility.  It's covered by my new suggested text
below.

Taking all that into account, here's my suggested text for the merge rules.

   For all the Path messages that share the same outgoing interface and
   next-hop LSR, the MP runs the following procedure to identify a Path
   message to forward downstream.

     1. If one or more of the Path messages is for the protected LSP,
        one of these must become the chosen Path message.  There should
        only be more than one in the case that the protected LSP is
        being rerouted.  In that case it is a local decision to choose 
        which one to forward.  Quit.

     2. From the remaining set of detour Path messages, eliminate from
        consideration those 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.

   Once the final Path message has been identified, the MP MUST start to
   refresh it downstream periodically.  Other LSPs are considered merged
   at this node.  For bandwidth reservation on the outgoing link, any
   merging should be considered to have occured before bandwidth is
   reserved.  Thus, even though Fixed Filter is specified, multiple
   detours and/or their protected LSP which are to be merged due to
   sharing an outgoing interface and next-hop LSR will reserve only
   the bandwidth of the final Path message on that outgoing
   interface.

   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 which cannot merge.

Thanks,

Nic

---

From: Der-Hwa Gan <[email-masked]>
Date: Fri, 18 Jul 2003 12:55:33 -0700

What do you guys think of the following text from Nic? I made a small adjustment
to part of the sentence (marked by ^^^), but didn't change anything else.
I think the merging rules are identical in semantics to what I last proposed, even
though the number of rules further reduce by 1.

It is possible to see detours conflict with each other that MP cannot find
a final Path message that satisfy all of them. In that case, the additional
text in rule 3 is necessary, as well as the last paragraph.

In the last paragraph, is it better to send patherr messages and fail the
merging, or simply pick one of the detours and continue the merge? If we
pick continue, some of the detours will provide link protections but
not node protection. Is that acceptable?

Thanks to Nic for pointing out the potential merging problem.
Der-Hwa

       1. If one or more 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),
	  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          one of these must become the chosen Path message.  There could 
							     ^^^^^^^^^^^
	  be more than one in the case that the protected LSP is
	  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          being rerouted.  In that case it is a local decision to choose 
          which one to forward.  Quit.

---

From: "Prabakaran T Sampath" <[email-masked]>
Date: Sat, 19 Jul 2003 13:30:54 +0530

Authors/Editors,

Please correct the following Typo error in
draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt.

In Section 14. Normative References,

   [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
   tunnels", RFC3029, December 2001.
             ^^^^^^^

The RFC3029 specified is a Typo error, it should be RFC3209.

Thanks and regards,
Prabakaran T.S.
Future Software Limited,
480-481, Anna Salai,
Chennai - 600035, India.
email : [email-masked]
Off Phone: +91-44-24330550 - Extn: 319
--------------------------------------

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Sat, 19 Jul 2003 14:43:48 +0200

thanks for having noticed it

JP