[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 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-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
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
>
>
> --
> 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