The MPLS WG Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi Ling,

At 17:20 24/01/2003 -0500, Ling Li wrote:
>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?

ok, let's remove "(i.e. only link protection is desired)"

In other words:
- flag set: if possible the PLR should always select a backup tunnel 
avoiding the NHOP.
- flag cleared: local PLR decision.

Thanks for your comments.

JP.

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


A very happy new year 2003 !

Jean-Philippe Vasseur - jpv@cisco.com
CISCO SYSTEMS
Technical Leader
IOS Engineering - Layer 3 Services
300 Apollo Drive
Chelmsford, MA - 01824
USA
Phone: 978-497-6238
Fax: 978-497-8126