[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New draft on Extra class LSP
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
>>>
>>>
>>
>>
>>
>
>
--
塩本公平
日本電信電話株式会社 未来ねっと研究所
電話 0422-59-4402 ファックス 0422-59-6387
〒180-8585 東京都武蔵野市緑町3-9-11
Kohei Shiomoto, Ph.D
Senior Research Engineer, Supervisor
NTT Network Innovation Laboratories
Phone +81 422 59 4402, Fax +81 422 59 6387
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan