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

Re: New draft on Extra class LSP

hi vishal

see inline

[snip]




-----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.)

I'm a little unclear what you mean here. As far as I can tell,
the terminology document uses the term "pre-planned LSP
restoration" (Section 7.1 of terminology doc.)
for the case when you have pre-planned rerouting
*with extra-traffic.* 
pre-planned lsp restoration or pre-planned lsp re-routing
refers to the same things (termino i-d):

"7.1 Pre-planned LSP Restoration

   Also referred to as pre-planned LSP re-routing."


Also, the definition of "extra-traffic" given earlier on in
the terminology document, seems to imply that "pre-emptible
low priority traffic" is precisely what extra-traffic is, whereas
in your earlier response you seem to distinguish between
the two.

come to the point please, "extra-traffic" is defined
section 4.2 of the terminology document and the use
of 1:1 lsp re-routing without extra-traffic (lsp) come
simply from the fact that the recovery lsp is not cross-
connected
since the
end-to-end association delivering path protection does not
allow to carry any extra-traffic, 

I agree that for the case of end-to-end path *protection*
it would be true that no extra-traffic is possible, by definition.
But then this would be because the resources in that case are
not only reserved, but also cross-connected. Thus, the issue
of extra-traffic does not even arise there.

we say the same thing here.


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)

Actually, for path *protection*, this is a moot point, since
no extra-traffic is possible there. Thus, the only case in which
extra-traffic comes into play is when one has pre-planned
restoration with extra-traffic. 
not true, 1:1 lsp protection allows for extra traffic
and is definitelly different from 1:1 lsp re-routing
in the latter case for the recovery lsp does not carry
extra-traffic, this is why and very logically it has
been referred to as 1:1 lsp re-routing without extra-
traffic (lsp), while in the former the lsp associated
to the recovery entity may carry extra_traffic


(That is, resources are set
aside for recovery, but are not cross-connected, thus allowing
for the reserved capacity to be used by other "extra-traffic"
LSPs (or low-priority pre-emptible LSPs).)
<<snip>>
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

Actually, I'm not sure one can have "LSP _protection_ with extra-traffic," (and Section 7 doesn't seem to have that category)
since in the case of protection, my understanding
is that no additional signaling should be needed, which would
imply that the backup resources are both reserved and cross-connected.
What one could have is pre-planned LSP re-routing with extra-traffic,
which is what I started the discussion with.
please re-read:
- for 1:1 lsp protection: section 6 of the termino and section 7 of
  the signaling i-d)
- for 1:1 lsp re-routing: section 7 of the termino and section 8 of
  the signaling i-d)



--
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