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

Re: New draft on Extra class LSP

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