The MPLS WG Archive

["Prabakaran T Sampath" <prabakarts@future.futsoft.com>]

Hi,

Please find my in lined comments [PrabakarTS].

Thanks and regards,
Prabakaran T.S.
Future Software Limited,
480-481, Anna Salai,
Chennai - 600035, India.
email : prabakarts@future.futsoft.com
Off Phone: +91-44-24330550 - Extn: 319
--------------------------------------

-----Original Message-----
From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of
Gopalkrishna Panicker
Sent: Friday, 18 July 2003 6:41 AM
To: mpls@uu.net
Subject: RSVP Fastreroute


All,

I have a few questions on RSVP fastreroute (draft-ietf
-mpls-rsvp-lsp-fastreroute-03.txt)

Consider the following network,

A---B---C---D---E---G
    |   |       |
    |---F-------|

Assume the following
The protected LSP has a ERO (ABCDEG)
1-to-1 backup is being employed.
All nodes are using Sender Template Method of backup
identification

Also,
B creats a backup LSP with ERO (BFEG)
C creats a backup LSP with ERO  (CFEG).

If I understand section 7.1.1 (Merging Backup Paths
using the sender template specific method) correctly,
one (and only one) path message will be sent/refreshed
from nodes F to E. The sender template in this path
message will belong to the winner of this merge.
Is this correct ? If so shouldn't the traffic spec of
this final path message reflect the traffic
requirements of the messages that have been merged.

>>[PrabakarTS] IMHO, as per the draft it was more clear the merging rules
>>at the point E in the above picture, for both Sender Template approach and
>>Path Specific approach.
>>
>>In section 7.1.1, the 3rd paragraph is bit ambiguous and it is not
>> addressing the issues at merge point at F,
>>
>>   "If merging occurs and all the Path messages were for backup LSPs,
>>   then the DETOUR object, if any, should be altered as specified in
>>   Section 8.1"
>>
>>In the above paragraph, it was stated with reference to Path-specific
>>approach(which basically uses DETOUR Object) merging rules
>>in the Sender-Template specific method.
>>
>>Authors/some experts, please clearly clarify this may be with some
>>example.
>>
>>For traffic spec of the merged final path message, since we are going to
>>use SE style for the reservation, the final traffic spec will be the
>>union of the traffic parameters of the merged LSPs.


Is this what the authors mean when they say in
paragraph 2 (line # 2)of section 7.1.1,
 "Similar to that specified in [RSVP-TE] for merging
of RESV messages,".

>>[PrabakarTS] Based on RFC 3209, section 2.4.3 explanation and in the
>>draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, Section 7.1.1 the merging
>>rule is "Outgoing interface and NHOP LSR are same and only those
>>Path messages whose ERO from that LSR to the
>>egress is the same can be merged."


So, if fastreroute is not being used, merging
will still occur the way I have described above
(assuming ofcourse that I am correct in the first
 place).

>>[PrabakarTS] The merging will occur based on section 2.4.3 in RFC3209.

If not, at a detour merge point how can
I tell the difference  between a detour LSP ( no
 DETOUR object  ) and a regular non-fastrerouteable
LSP i.e one should be merged and one should not.


>>[PrabakarTS]  We can distinguish this, based on either FAST-REROUTE Object
or
>>Local protection desired flag set in the SESSION-ATTRIBUTE Object.


Thanks in advance,

Cheers,
Gopal



__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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