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

Re: New draft on Extra class LSP

vishal,

see in-line...

Vishal Sharma wrote:

[snip]


If that is so, then it appears that you are limiting the definition of
"extra-traffic" to merely traffic that has the exact same ingress-egress
as the working path for which the recovery resources are reserved.

you should make a distinction between the "extra-traffic lsp"
meaning the lsp establish to protect the working lsp from
the "traffic" in itself when carried over such lsp/span's is
referred to as "extra-traffic", i think this where the whole
point is


So if all of the above are true, the following needs to happen:

i think that what should first happen, is that you call a
cat a cat, if an lsp is establish using preemptible recovery
resources there is no reason to call it "extra-traffic lsp"
it is simply a "lower priority (preemptible) lsp"


i) The definition of "extra-traffic" needs to be made very precise in the
terminology doc. (At present, it seems to have the meaning that I have
defined above in brackets **).

i think the definition is as precise as it can be for the
definition of extra-traffic (as said above you should diff.
the lsp with the definition of the traffic it carries)


ii) The terminology document needs to clearly define/state that the
resources reserved but not cross-connected can be reused by low-priority,
pre-emptible LSPs, and that the setting up of those is outside the scope
of the P&R doc.

an i-d says what it does and refers to other, i-d's when
it borrows mechanisms that it uses, in the present scope
setting up "lsp's with a given priority" is a well-known
mechanism as well its hard (see rfc3473) and soft (see
2205/3209) preemption


iii) We need to have further discussion of Shiomoto-san's draft, to see
if what is proposed there can be accomplished by existing mechanisms?
(I think Shiomoto-san made a good point about not using the existing
priority mechanisms (that work for service differentiation between
LSPs of the _same type (all working or all recovery)) to distinguish
between extra LSP and low-priority LSP.)

yes, and this is what i understood from him as well but
before that it is still very unclear what is the real
purpose of it ? and it would be of interest why this
is not enough to have achieve a common baseline ? what's
missing to be capable to setup "low priority lsp's using
preemptible resources" from the set of gmpls i-d's ?


iv) The terminology and signaling documents need to make clear that
even in the case of 1:1 LSP re-routing without extra-traffic, the reserved
resources can be used by (using Shiomoto-san's term) extra LSPs (since as
he rightly observes, extra-LSPs are not pre-empted based on traffic volumes,
only upon a failure in one of the working paths whose recovery requires
resources
being used by an extra LSP).

well i think it is clear that we do not cover other
aspects than re-using recovery resources upon failures
(as defined in the terminology) of the working resources,
but this is to have a specific scope and goal based on
what p&r means

thanks,
- dimitri.


Also, see some comments in-line.

-Vishal



-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Friday, July 04, 2003 3:23 AM
To: v.sharma@ieee.org
Cc: Kohei Shiomoto; Adrian Farrel; ccamp@ops.ietf.org
Subject: 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





<snip>




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




I fully understand that pre-planned LSP restoration and
pre-planned LSP re-routing are the same thing. That wasn't my
question. I asked whether pre-planned LSP rerouting, _in its
very definition_, means you can use the reserved (but not cross-connected)
resources for "extra traffic"?

(I understand the phrase "not cross-connected" to simply mean that the
intervening cross-connects aren't configured to carry the traffic
of a specific working path, but (since link resources have been reserved
anyway)
they could be configured to carry other traffic (the "extra traffic").)

If yes, then I'm not sure what "pre-planned LSP rerouting without
extra traffic" means.
If no, then the definitions in the terminology document
need to be improved, as that isn't what one necessarily gets by
reading the definition in Section 7.1.






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










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