The MPLS WG Archive

[Ling Li <lli@axiowave.com>]

The following are my comments and questions on the draft. Your
clarifications are appreciated. --Ling

1. The assumptions made in the draft:
	1). From Section 7: 
	"Therefore, an LSR which is on the path
	of a protected LSP SHOULD always assume that it is a merge point"

	2). From Section 8:
	"if a DETOUR object is included in the backup LSP's path
	message for the sender-template-specific method, the LSRs in the
      traffic-engineered network should support the DETOUR object.

   	Second, if the Path-Specific Method is to be supported for
      the one-to-one backup technique, it is necessary that the LSRs in
      the traffic-engineered network be capable of merging detours "

These are very important assumptions. Could these assumptions be mentioned
in the 
Introduction section to avoid confusion when reading the first several
sections?
For example, the hop-limit constraint in Section 4.1 is very confusing
without
assumption 1).

Questions: 
1. Is the following assumption implied by the draft:
an LSR which is on the path of a protected LSP SHOULD always assume that 
it is a PLR.

Without this assumption, the NHOP or NNHop bypass may not work as expected.
That is because NHOP bypass can only protect a downstream neighbor link. If
the downstream neighbor node is not a PLR, a failure of the remote
downstream
link is going to be propagated to the current node. If the current node
knows
that its downstream neighbor is not a PLR, it may use NNHop to protect the 
neighbor node and the remote downstream links. Since the current node has no
way
to know if the downstream neighbor is PLR, I guess it is assumed.

2. I think the following statements in Section 4.2 is not needed because
of assumption 2).
"LSRs that do not support the DETOUR objects MUST reject any Path message 
containing a DETOUR object and send a PathErr to notify the PLR."
If really needed, please provide Error Code and Value. Hard to imagine
anyone
will upgrade their code for not supporting a feature.

Some general comments:
1. in Section 6.2, "For detour LSPs, the destination MUST be the tail-end of
the protected LSP". However the hop-limit constraint is "from current node
(a PLR) 
to a MP". It is not easy to enhance cspf to support this constraint if 
it is defined this way. I would prefer not setting constraint to MP, but to
the destination, such as what is de	fined in Juniper product:
"For fast reroute, how many more routers a detour is allowed to traverse
compared 
to the LSP itself" at
http://www.juniper.net/techpubs/software/junos52/swconfig52-
mpls-apps/html/mpls-summary18.html#1014333.

2. The following statement is not very clear in Section 5:
"If node protection is desired, the head-end LSR should set the "node
protection desired" flag in the SESSION_ATTRIBUTE object; if only link
protection is desired, this flag should be cleared. " 
Could it be changed to use Otherwise after the first half of the statement,
jus as
what is said for "bandwidth protection desired" flag after the statement. 

3. The following statement is made is Section 6:
"  If the "node protection desired" flag is set, the PLR SHOULD try to
   provide node protection; if this is not feasible, the PLR SHOULD
   then try to provide link protection."
Can we say the same for "bandwidth protection desired" flag? 
"  If the "bandwidth protection desired" flag is set, the PLR SHOULD try to
   provide bandwidth protection; if this is not feasible, the PLR SHOULD
   set the bandwidth constraint to 0 then try to provide protection."




> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Tuesday, December 03, 2002 5:50 PM
> To: mpls@UU.NET
> Subject: Last Call on Fast Reroute
> 
> 
> This message begins a workgroup last call on:
> 
> Fast Reroute Extensions to RSVP-TE for LSP Tunnels
>     
>   draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt
> 
> The last call ends on Dec 16, 2002 2400H GMT.
> 
> George & Loa
> 
> ======================================================================
> George Swallow          Cisco Systems                   (978) 497-8143
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824
> 
> 
>