[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New draft on Extra class LSP
Hi Dimitri,
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Dimitri.Papadimitriou@alcatel.be
> Sent: Thursday, July 03, 2003 2:45 AM
> To: Kohei Shiomoto
> Cc: Adrian Farrel; ccamp@ops.ietf.org
> Subject: Re: New draft on Extra class LSP
>
>
> hi adrian, kohei,
>
> in the case of pre-planned re-routing without extra-traffic
> the unallocated protecting resource can be used by other
> (lower priority LSPs) at the condition that the resources
> are preempted when the working LSP fails (hint: i wanted
> to point out also that this should be obvious otherwise
> there is no reason for having this "path protection only")
Actually, I think the terminology choice "without extra-traffic"
is a bit confusing. It wasn't clear how the document distinguishes
between "extra traffic" and "low priority traffic that can be
pre-empted"?
> and the below i-d points out specific aspects (that are
> covered "partially" by other gmpls i-d's) see below:
> - advertize the bandwidth: -> gmpls-routing (and bw acct)
> - extra class LSP indication in signaling message -> priority
> in (g)mpls signaling
> - extra class LSP preemption signaling -> PathErr with SR
> Flag and PathTear (to release the lower priority LSP)
> but this can be qualified here as an "hard preemption"
> mechanism
> - preventing unintended connections -> it is a transient
> behaviour that may occur at an intermediate node e.g.
> if the previous point is not used, and cross-connection
> is fully performed in the downstream direction
>
I endorse the need to focus seriously on the last point, since,
if during dropping "extra traffic" or "low priority pre-emptable traffic",
the intermediate nodes end up misconnecting traffic (even for a short
while), it would be a real violation of SLAs. I would suspect it
would make customer's with mission critical traffic (and their
service providers, implementing such a scheme) very uncomfortable to know
that this is even a remote possibility! :-)
-Vishal
>
> Kohei Shiomoto wrote:
> > Hi, Adrian
> >
> > In Section 9 of draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt,
> > the shared mesh restoration is addressed. Extra traffic cannot be
> > carried because the protecting LSPs are not instantiated in shared mesh
> > restoration networks. But the resource for the protecting LSPs are
> > reserved to back up the failure of primary LSPs. The reserved resource
> > could be allocated for extra traffic to enhance the network utilization.
> >
> > The purpose of our draft is to initiate the discussion on how to handle
> > extra class LSP using the reserved link resource for the
> protecting LSPs
> > while the draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt
> addresses
> > the signaling of primary and protecting LSPs.
> >
> > Regarding extra class LSP, the following issues need to be addressed:
> > (1) advertisement of available resource for extra class LSP, (2) extra
> > class LSP indication in signaling message (3) extra class LSP
> preemption
> > signaling, and (4) preventing unintended connections. Our draft
> provides
> > the problem statement of these issues.
> >
> > Hope this clarify the difference.
> > Thank you for your interest.
> > ---
> > Kohei
> >
> >> Shiomoto_san,
> >>
> >> Could you help us prepare for Vienna by summarizing the difference
> >> between
> >> your draft and
> >> draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt especially with
> >> reference to the carrying of "extra traffic" on the resources of a
> >> protection path in a mesh network.
> >>
> >> Thanks,
> >> Adrian
> >>
> >> ----- Original Message -----
> >> From: "Kohei Shiomoto" <Shiomoto.Kohei@lab.ntt.co.jp>
> >> To: <ccamp@ops.ietf.org>
> >> Sent: Tuesday, July 01, 2003 3:18 AM
> >> Subject: New draft on Extra class LSP
> >>
> >>
> >>
> >>
> >>> Sorry for the incorrect subject in the previous mail. I
> resend it with a
> >>> new subject.
> >>>
> >>> Hi, all
> >>>
> >>> Please notice that a new internet-draft has been posted. The draft is
> >>> targeted at the IETF57 ccamp meeting. The draft is prepared
> to initiate
> >>> the discussion at the ccamp-wg on the extra class LSP service, which
> >>> makes use of reserved but unallocated bandwidth for the
> protecting LSPs
> >>> in the pre-planned LSP re-routing recovery method (including
> shared mesh
> >>> restoration). Comments and feedbacks are highly appreciated.
> >>> Thanks.
> >>> --
> >>> Kohei Shiomoto
> >>> NTT Network Innovation Laboratories
> >>> Phone +81 422 59 4402, Fax +81 422 59 6387
> >>> 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
> >>>
> ------------------------------------------------------------------
> --------
> >>>
> >>>
> >>
> >> ----------------------
> >>
> >>
> >>> Title : Extra class LSP service using protecting
> resources in
> >>> GMPLS networks
> >>> Author(s) : K. Shimano et al.
> >>> Filename : draft-pil-ccamp-extra-lsp-00.txt
> >>>
> >>> This document provides the problem statement on a extra class LSP ser-
> >>> vice and addresses the issues. The extra class LSP uses the resource
> >>> reserved but not allocated for the protecting LSPs in the pre-planned
> >>> LSP re-routing without extra-traffic (including shared mesh) recovery
> >>> method. Network utilization is improved because the resource reserved
> >>> for the protecting LSPs are used for the extra class LSPs. The extra
> >>> class LSP is preempted less frequently than the conventional priority
> >>> mechanism using setup and holding priorities because the resource
> >>> reserved for the protecting LSPs is allocated only if the working LSP
> >>> fails, which is usually expected to rarely occur. This document pro-
> >>> poses the extra class LSP service using the resource reserved but not
> >>> allocated for the protecting LSP at the provisioning phase.
> This docu-
> >>> ment addresses the issues on the extra class LSP: (1) advertisement of
> >>> available resource, (2) extra class LSP indication in
> signaling message
> >>> (3) extra class LSP preemption signaling, and (4) preventing
> unintended
> >>> connections.
> >>>
> >>> A URL for this Internet-Draft is:
> >>> http://www.ietf.org/internet-drafts/draft-pil-ccamp-extra-lsp-00.txt
> >>>
> >>
> >
> >
> >
> >
>
>
> --
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone : +32 3 240-8491
>
>