RE: New draft on Extra class LSP

["Vishal Sharma" <v.sharma@ieee.org>]

Dimitri,

(A) I see your point about reusing the priority mechanism to setup
low-priority pre-emptible LSPs over the resources reserved for
restoration. However, there is still the issue that such LSPs
ought not to be pre-empted by anything other than working LSPs
that need to use those recovery resources. They should not, for example,
be pre-empted by other higher priority LSPs (whether working or
protection LSPs).

So, it appears there does need to be some thought given to how
this will be achieved, and how the resources reserved for
restoration will be advertised. 

Perhaps it is matter of sitting down and working through a priority 
allocation scheme to these
different types of LSPs that will achieve such consistent behavior.
The point being that some thinking along those lines is needed, 
which is what the extra-class LSP draft, I guess, tries to initiate.

(B) Now a question about the definition of "extra traffic" 

Are _both_ of the following "extra traffic" per the 
terminology draft?

i) Traffic that uses resources reserved and cross-connected for
a protection path, and travels between the same source-destination pair
as the protection path.

ii) Traffic that uses resources reserved (but not cross-connected)
for recovery. This traffic is sent by setting up low-priority
pre-emptible LSPs on those reserved resources.

From your initial reply to Shiomoto-san (repeated below so people
can follow the context) and some of your subsequent
explanation it appears that this is the case (since you said that
this definition is designed to "cover any cases of extra-traffic
that we may encounter").

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

If so, the term "pre-planned re-routing without extra traffic" is circular,
since the type of traffic that can used those pre-planned (but
not cross-connected) resources is "extra traffic." 

If not, then it appears that "extra-traffic" only covers traffic
of type (i) above, and the definition should make that clear.
Or else, the term "pre-planned re-routing without extra traffic"
should be changed to be consistent with the terminology doc.


-Vishal

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Saturday, July 05, 2003 5:01 AM
> To: v.sharma@ieee.org
> Cc: Kohei Shiomoto; Adrian Farrel; ccamp@ops.ietf.org
> Subject: Re: New draft on Extra class LSP
> 
> 
> vishal,
> 
> [snip]
> 
> > In the latter case, however, the only way any traffic could use the
> > reserved resources would be for one to setup a low-priority, 
> pre-emptible
> > LSP using those resources, with the distinction that these particular
> > low-priority LSPs are not subject to pre-emption unless a working
> > LSP that needs to use those reserved resources fails (This what
> > Shiomoto-san more accurately calls "extra-LSP".)
> 
> the point is to have a network wide homogeneous allocation
> of resources, starting to have allocation based on the
> reason why the lower priority lsp can be preempted leads you
> to the issue of how many of such conditions can we have
> in a network ? or do you plan to start defining one class
> of lsp and priority per such event ? the idea behind the
> "re-use" of these preemptible resources is to abstract its
> complexity not to spread it network wide - this while what
> we have today works perfectly -
> 
> > So let's call an "extra-traffic LSP" an "extra-traffic LSP" :-) 
> and let's
> > clearly define "extra traffic" in the terminology doc., because I don't
> > think the definition, as it stands, in precise enough, unfortunately.
> 
> the proposed definition (in the terminology i-d) is generic
> enough to cover any cases of extra-traffic that we may
> encounter, as said before in the "e2e" signaling i-d this
> definition is applied in this "e2e" context, there is here
> absolutely no reason (for the time being) to change the
> definition in the terminology document due to its usage
> in the signaling i-d - the only reason to change a def.
> in the terminology i-d would be that it doesn't cover the
> case of a concept developed in one of the subsequent i-d's
> not the other way around
> 
> thanks,
> - dimitri.
> 
> 
>