RE: New draft on Extra class LSP

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

Hi Dimitri,

Thanks for the clarifications.

Some comments in-line.

-Vishal

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Sunday, July 06, 2003 2:15 PM
> To: v.sharma@ieee.org
> Cc: Kohei Shiomoto; Adrian Farrel; ccamp@ops.ietf.org
> Subject: Re: New draft on Extra class LSP
>
>
> vishal,
>
> point A has been clarified on the list (and i think that
> the suggestion that was made/received on the list makes
> perfectly sense)

I'm assuming the suggestion you refer to above is yours and/or
Adrian's endorsement of your explanation.
Namely, use the reserved (but not cross-connected)
resources for setting up low-priority LSPs using available
mechanisms.

As I said, this is fine, with the caveat that one has to
then come up with an appropriate priority scheme that will
satisfy the requirement that such LSPs not be pre-empted
during the ordinary course of events (and only be pre-empted
when a working LSP needs to use the resources being used by
these LSPs).

I'm not saying it cannot be done, I'm just saying it needs
some thought and is not obvious (at least to me).

> point B (note: in your e-mail neither i) or ii) translates
> exactly the terms of the terminology draft, and none of your
> inferences are entirely correct, i have explain it to you
> already) in particular after the clarification on point A
> has been given, the term "1:1 re-routing without extra-traffic"
> (ref. also in the terminology i-d) should have been also
> understood that it meant that *this recovery lsp* (+) is not
> able to carry any traffic referred (per the terminology i-d)
> as "extra-traffic" (if this lsp would have been fully
> provisioned) what you call circular is just consistence.
>
> (+) from the early beginning you refer to other lsp's (ie
> the lower priority ones - see point A) than the one the sig
> i-d refers to for this recovery type
>

I'm sorry, but I'm still not clear on the meaning of "extra traffic."
Perhaps I need to go back and look again at it, and think about it
a bit.
I'll then come back with any follow-up questions, either on the list
or perhaps discuss off-line.

As an alternative, perhaps some other folks on the list who are clear
on these definitions could take a stab at helping those of us who are still
unclear understand them.
(And, I'd certainly like to find out from the list,
if I'm the only one confused here, and, if so, see if people can point
me in the right direction.)

>
> Vishal Sharma wrote:
> > 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.
> >>
> >>
> >>
> >
> >
>
>
> --
> 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
>