RE: New draft on Extra class LSP

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

Dimitri,

I think we're getting to a clearer definition of things ...

Some comments in-line.

Thanks,
-Vishal

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

It appears then that an "extra-traffic LSP" is really a backup LSP
that has been _set up_ between a certain ingress-egress pair
(namely for which resources have been both been
reserved and cross-connected), and "extra traffic" is traffic
that uses the resources of such an LSP.

My point is that the current definition of "extra traffic" in the
terminology document does not make this clear.

Upon reading that definition, one comes away with the impression
that traffic that
uses the resources of a previously set up backup LSP _or_ traffic
that uses the resources that have merely been reserved for a backup
LSP, but haven't been cross-connected, are _both_  "extra traffic."

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

Also, if we indeed call a "cat a cat" :-), then for everything other
than 1:1 protection/restoration, there would really be no "extra-traffic",
only low-priority, pre-emptible LSPs that happen to use the resources
reserved (but not cross-connected) for shared recovery.

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.

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