The MPLS WG Archive

[Ping Pan <pingpan@cs.columbia.edu>]

Shahram Davari wrote:

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


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.

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


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.

 

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


Yes. OK.


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


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.


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


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.


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


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
> protections are available?
> 


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