Subject: Comments on Fast Reroute draft

From: Shahram Davari <[email-masked]>
Date: Fri, 9 Aug 2002 08:02:33 -0700

Hi,

Please find below some comments on the fast-reroute draft:

1) Why do we need to specify the BW in the FAST_REROUTE object, while
it is already signaled in the RSVP?

2) Is the meaning of the following flags combinations in session_attribute as indicated:

(Local protection desired =0) & (Node protection desired =0)-> No protection
(Local protection desired =0) & (Node protection desired =1)-> Node protection
(Local protection desired =1) & (Node protection desired =0)-> Link protection
(Local protection desired =1) & (Node protection desired =1)-> Node protection
(Local protection desired =1) & (no Session_Attribute object)-> Local policy

Please clarify the correct meaning in the text.

3) Section 3.5 defines the BW protection ration as:

"The BW of all the protected LSPs having selected T as their bypass tunnel /
BW of the bypass tunnel"

but it mentions that: "the minimum value for the protected ratio is 1"

As mentioned in the backup-computation draft, it is possible to backup
an LSP without reserving BW for it in the bypass tunnel. So Min =1
seems not to be correct.

4) Section 4.1: (identification of backup paths)
The Sender_template specific identification, does not have any specific text to
show how it is used by an LSR to identify the backup path. Is it done by comparing the Extended tunnel ID with the sender IPV4 address?

Please provide accurate text.

5) Section 5.1 says:

"  A one-to-one
   backup for a protected LSP may also be created based upon a PLR's
   local policy if either the "local protection desired" flag is set in
   the SESSION_ATTRIBUTE object or a FAST_REROUTE object is included or
   both.
"
 Do you mean a FAST_REROUTE object with Node protection desired =1. If so
please clarify.

6) Section 5.3 repeatedly says selecting final LSP from a number of path messages. I think mentioning of LSP is not accurate, rather "selecting final PATH message" is the more accurate term.

7) Section 5.3 :

Since bullet 4 eliminates all LSPs with Detour object, how is bullet 4 possible?

Since as stated in section 7, each PLR has option to apply its own constraints, then each PLR  may reach to a different backup-path ERO for the same flow. Assuming that the EROs have a single link (the downstream link of an MP LSP) in common, isn't it wrong for an MP LSR to merge those Path messages?

8) Section 6.1: Global-to-node label is not a defined IETF term. Suggest changing it to Per-platform.

9) Section 7 states that :

"When setting up one-to-one protection using the path-specific
 approach, a detour MUST not traverse the upstream links of
 the protected LSP in the same direction.  This prevents the
 possibility of early merging of the detour into the protected
 LSP."

I think instead the rules of merging should be defined so that this can't happen.

10) Section 7.1 talks about path-protection. Where is this defined in context of fast reroute?

11) Section 8.1 talks about sending Path Error to notify the ingress LSR
of the fast protection event. For how long and with what intervals is this
Path_ERROR transmitted?

12) Section 9.2 permits having both types of protection (1-to-1 and facility) for the same PLR. In that case how can it inform the ingress LSR that both
protections are available?

Yours,
Shahram

---

From: Ping Pan <[email-masked]>
Date: Fri, 09 Aug 2002 09:56:06 -0700

> it is already signaled in the RSVP?

The resources that are needed for fast reroute may not be the same as 
the regular LSP. For example, all backup traffic could have zero 
bandwidth requirement, but EXP bit on.

> Please clarify the correct meaning in the text.

What's been described in SAO is a user's desire. The routers may not be 
able to support it. For example, when a user asks for 
local-protection-desired and node-protection-desried, if a backup LSP 
cannot be established to skip the node, well, tough! ;-) Depending on 
the implementation, link protection may be used only instead.

> show how it is used by an LSR to identify the backup path. Is it done by comparing 

> the Extended tunnel ID with the sender IPV4 address?
> 

Yes. OK.

>  Do you mean a FAST_REROUTE object with Node protection desired =1. If so

No. One-to-one can do link protection as well. I will add more text on 
this. Thanks!

> 6) Section 5.3 repeatedly says selecting final LSP from a number of path messages. 

> I think mentioning of LSP is not accurate, rather "selecting final PATH message" is the more 

> accurate term.

Yep.

> I think instead the rules of merging should be defined so that this can't happen.

OK.

> 10) Section 7.1 talks about path-protection. Where is this defined in context of fast reroute?

It's in the context of co-authors were thinking and talking about 
different things during our merging. At the end, we just forgot about 
it. ;-) Will fix it asap.

> of the fast protection event. For how long and with what intervals is this

Path_Error messages are reference messages to the ingress. In other 
words, they are not that important. So a router can take its time to 
send the error messages. BTW, when a link/node goes down, it is possible 
that a router shoots out multiple error messages. One is to inform the 
ingress that the link/node is found to be dead. After the local repair, 
the node will tell the ingress "the LSP has been locally repaired".

> 12) Section 9.2 permits having both types of protection (1-to-1 and facility) for the same PLR. 

> In that case how can it inform the ingress LSR that both

RRO tells the ingress that the traffic has been protected. Is it enough? 
  If not, there is a MIB draft on fast-reroute. ;-)

Thanks!

- Ping