[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New draft on Extra class LSP
Yoshihiko,
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Yoshihiko SUEMURA
> Sent: Saturday, July 05, 2003 1:50 AM
> To: Dimitri.Papadimitriou@alcatel.be; Kohei Shiomoto
> Cc: v.sharma@ieee.org; Adrian Farrel; ccamp@ops.ietf.org
> Subject: Re: New draft on Extra class LSP
>
>
> Dimitri,
>
> Are you saying the following?
>
> - In Shared Mesh Restoration, bandwidth reserved for recovery LSPs can
> be advertised by using the "Max LSP Bandwidth at priority
> X" field in
> the Interface Switching Capability sub-TLV.
>
> - You can setup a low priority LSP (or an Extra-LSP) by
> setting priority
> X at the Setup Priority field of the Session Attribute
> object in the RSVP
> message.
This is exactly right. We should probably add these two bullet points
to the P&R drafts for clarification.
Thanks,
Jonathan
>
> This makes sense to me. But, I am still wondering if it is
> the way the priority mechanism should be used.
>
> Regards,
>
> Yoshihiko
>
> On Fri, 04 Jul 2003 14:04:04 +0200,
> Dimitri.Papadimitriou@alcatel.be wrote:
>
> > hi kohei,
> >
> > in between "1:1 lsp protection with extra-traffic lsp" (covered in
> > section 6 of the termino and section 7 of the signaling
> i-d) and "1:1
> > lsp re-routing without extra-traffic lsp" (defined in
> section 7 of the
> > termino and section 8 of the signaling i-d) where it is
> assumed that
> > these resources can be re-used by lower priority lsp which is of
> > course *not* the recovery lsp associated to the working
> lsp, i do not
> > see where additional markup is needed from a signaling perspective
> > (since these extra-traffic lsp have their specific bit
> setting in the
> > protection object), while the lower priority lsp
> established using the
> > preemptible recovery resources are also signaled using
> existing rfc's
> > and wg i-d's (but this is not within in the scope of the
> signaling i-d
> > i am referring to), and for what relates to the signaling
> i-d i think
> > that the distinction has been clearly made for the
> extra-traffic lsps
> > (that can or not carry carry traffic).
> >
> > now of course you can always tell me here the following: once the
> > recovery lsp is (control-plane) established in a
> shared-mesh recovery
> > scheme, it gives raise to a "new class" of resources from which the
> > resources have been pre-selected but the assumption made
> here (see the
> > analysis i-d) is that this pool is already within the priority list
> > already made available in gmpls-routing i-d's isc sub-tlv - this is
> > the baseline from which we started in atlanta (note: this
> may evolve
> > but i don't have for the time being any strong rationale to
> make this
> > evolving except that it would complexify the control of an already
> > complex recovery scheme - i mean here shared mesh recovery).
> >
> > what i would thus suggest, since by the time even the relatively
> > simple recovery schemes have already shown to be more complex (than
> > expected) once control plane driven, it is to clearly
> provide us, the
> > (potential) rationales to perform this separation and
> achieve further
> > expected optimization or see it from the other way around - because
> > this is probably the main issue - what are the protocol
> aspects that
> > are not affected by the current baseline, that would be in
> case such
> > kind of mechanism is introduced ? in any case you would fall into a
> > scope that we don't cover here since the proposed approach does not
> > assume any additional gmpls routing extensions (see also
> conclusion of
> > the analysis i-d, thus here i do not think appropriate to
> make a come
> > back now on a consensus made last year) but if people can
> demonstrate
> > that new paradigms and further optimization based on gmpls-routing
> > extensions would better meet their future expected needs
> and thus fall
> > into a new charter item, really fine with me (i would be
> glad to help
> > in this effort, in
> > case)
> >
> > thanks,
> > - dimitri.
> >
> > Kohei Shiomoto wrote:
> > > Hi, Dimitri,
> > >
> > > In the extra LSP draft, we want to make clear distinction between
> > > lower priority LSP and extra LSP.
> > >
> > > Priority mechanism is used to differentiate the service
> quality for
> > > working resource. The resource for working LSPs is contended by
> > > working LSPs of different priority classes. Service quality is
> > > dependent on traffic ratio of different priority classes; service
> > > quality of lower priority LSP degrades if higher priority LSP
> > > request comes frequently. Resource for protecting LSP in
> shared mesh
> > > restoration is preempted only when the working LSP fails. Service
> > > quality does not depend on traffic ratio of different priority
> > > class. We could define another service class which does
> not depend
> > > on the traffic ratio of different priority class by using
> resources
> > > for protecting LSP in shared mesh restoration. Priority
> mechanism is
> > > used for service differentiation based on relative traffic volume
> > > difference while extra LSP is preempted only when the working LSP
> > > fails. So we should make distinction between lower
> priority LSP and
> > > extra LSP.
> > >
> > > Thanks.
> > > --
> > > Kohei
> > >
> > >
> > >>hi vishal,
> > >>
> > >>see in-line...
> > >>
> > >>Vishal Sharma wrote:
> > >>
> > >>
> > >>>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"?
> > >>
> > >>
> > >>it distinguishes between protection and (pre-planned) re-
> routing,
> > >>for the former it thus refers to protection with
> extra-traffic & the
> > >>latter re-routing without extra-traffic (see also section
> 7.1 of the
> > >>terminology doc.) since the end-to-end association
> delivering path
> > >>protection does not allow to carry any extra-traffic, now
> the fact
> > >>that these resources can be used for lower priority
> traffic boils us
> > >>down to the setup of low priority lsp (that may be thus
> > >>preempted) but this is not anymore a specific "p&r" issue
> > >>except the fact the trigger for this preemption is internal
> > >>to the network and not an external provisioning or config
> > >>event (but anyway an additional sentence here would more
> > >>than certainly not hurt)
> > >>
> > >>
> > >>>>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.
> > >>
> > >>
> > >>well the issue i wanted to point out is that these lower priority
> > >>lsp's can be established outside of the scope of the p&r
> context it
> > >>refers to larger scope issue (*) - note that this
> misconnection (as
> > >>currently specified) does not occur for lsp protection with
> > >>extra-traffic (see section 7) or if you want the only reason for
> > >>preemption is protection switching that occurs only on and end-to
> > >>end basis
> > >>
> > >>(*) i refer here to the mpls mailing list discussion
> > >>
> > >>thanks,
> > >>- dimitri.
> > >>
> > >>
> > >>>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-0
> > >>>>>>>0.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
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >
> >
> >
> > --
> > 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
> >
> >
>
>
> -----------------------------------------------------------------
> Yoshihiko SUEMURA
>
> Networking Research Laboratories,
> NEC Corporation
> E-mail: y-suemura@bp.jp.nec.com
> Phone: +81 44 856 8109, FAX: +81 44 856 8071
>
>