The MPLS WG Archive

[Ling Li <lli@axiowave.com>]

Hi, Alia,

Thanks for the response. Your answers to my comments and questions sound
good
over all. Some minor comments are inline. My original message was clipped.

Thanks, 

Ling Li 

Axiowave Networks, Inc. 
200 Nickerson Road 
Marlborough, MA 01752 
Phone: (774)348-4618 
Fax:   (774)348-4008 
Email: lli@axiowave.com 
======================== 



> -----Original Message-----
> From: Alia Atlas [mailto:aatlas@avici.com]
> Sent: Monday, January 20, 2003 9:17 AM
> To: Ling Li
> Cc: 'mpls@UU.NET'; Ping Pan; Jean Philippe Vasseur; Der-Hwa Gan;
> mjork@avici.com; dcooper@gblx.net
> Subject: RE: Last Call on Fast Reroute
> 
> 
> Ling,
> 
> Sorry for the delay in response.
> 
> 
> How does the following paragraph sound?
> 
> "For the techniques discussed in this document to function properly,
>     there are three assumptions which must be made.  First, an LSR

I did not see the third assumption here. Should it be two?

>     which is on the path of a protected LSP SHOULD always assume that
>     it is a merge point; this is necessary because the facility backup
>     method does not signal backups through a bypass tunnel before
>     failure.  Second, if the one-to-one backup method is used and a
>     DETOUR object is included, the LSRs in the traffic-engineered
>     network should support the DETOUR object; this is necessary so that
>     the Path message containing the DETOUR object is not rejected.
>     Understanding of the DETOUR object is required to support the
>     path-specific method which requires that LSRs in the
>     traffic-engineered network be capable of merging detours."

> 
> Whether an LSR can function as a PLR determines whether a 
> potential failure 
> condition can be quickly healed.  Consider the following diagram.
> 
>                  [R1]-------[R2]------[R3]------[R4]
>                          \             |               \     /
>                            [R5]---[R6]-----------[R7]
> 
> In this diagram, if R3 can not function as a PLR, if the link 
> R3-R4 fails, 
> there is no immediate repair possible at R3.  R2 will get a 
> PathErr and can 
> use its backup, if it is NNHOP.  Regardless of whether R2's 
> backup is NNHOP 
> or NHOP, the fail-over time is longer than desirable because there is 
> signaling required from R3 to R2.  Does this help answer the question?

Thank you!
 
> This PathErr is part of RFC 2205.  In Section 3.10 there, it 
> says that for 
> objects with an unknown class-num of the form 0bbbbbbb, "The 
> entire message 
> should be rejected and an "Unknown Object Class" error returned.
> 
> I will add a reference to this in the draft so that the 
> paragraph at the 
> end of Section 4.2 reads:
> 
>   "The high-order bit of the C-Class is zero; 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.  This PathErr SHOULD
>     be generated as specified in [RSVP] for unknown objects with a
>     class-num of the form "0bbbbbbb"."

Sounds good

> 
> This is equivalent.  The detour will traverse from the merge 
> point to the 
> egress along the path of the LSP.  Therefore, the additional 
> hops are those 
> in the detour not including the PLR or the merge point.  This 
> definition 
> came from the initial draft describing the detour method.

OK.

> Sure, I'll put otherwise in there as
> 
>    "If node protection is
>     desired, the head-end LSR should set the "node protection desired"
>     flag in the SESSION_ATTRIBUTE object; otherwise (i.e. only link
>     protection is desired), this flag should be cleared."

The point I was trying to make was that NO "node protection desired"
is different from "link protection desired". In the first case, an 
implementation may first try to provide node protection; if not possible,
then try to provide link protection. However in the second case, if the
flag is cleared means "link protection desired", an implementation has to
try to provide link protection first. May I suggest to remove "(i.e. only
link protection is desired)" from the above paragraph, or define clearly
the behavior of "otherwise" in Section 6?

> We can certainly put in that the PLR SHOULD try to provide bandwidth 
> protection.  However, saying that the PLR should set the bandwidth 
> constraint to 0 is, I think, not appropriate for all cases.  
> For instance, 
> with the facility backup, a bypass tunnel may have its bandwidth 
> over-booked such that a bandwidth guarantee can not be 
> provided, but that 
> doesn't mean that the backup can't be created and may have 
> better bandwidth 
> protection than 0.  I'll amend the paragraph as follows.
> 
> "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.  If the "bandwidth protection
>     guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth
>     guarantee; if this is not feasible, the PLR SHOULD then try to
>     provide a backup without a guarantee of the full bandwidth."

Very good.