[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New draft on Extra class LSP

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