The MPLS WG Archive

[Alia Atlas <aatlas@avici.com>]

Ling,

Sorry for the delay in response.

At 08:23 PM 12/12/2002 -0500, Ling Li wrote:
>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).

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


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

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?

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

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

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

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.

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

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

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

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

Does this sound ok?

Thanks,
Alia

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