RE: New draft on Extra class LSP

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

Dimitri,

Let me just recap what I think I understand so far. We can then discuss
the specific areas in which I think the documents need to be clearer.

First, from the definitions in the terminology doc., Section 4.3 A and B,
backup resources are reserved _both_ in the case of protection and
restoration.

The difference being that for protection, they are also cross-connected
(because
it is known exactly which working LSP a given backup LSP will protect).
For restoration, the resources are reserved but not cross-connected,
because, barring the 1:1 case, in any shared scheme (1:N, M:N, shared mesh),
it isn't known which particular working path the backup resources
may end up protecting.

Now "extra-traffic" could be carried in _both_ of the above cases. **
(If we
assume that "extra-traffic" is simply traffic that is using recovery
resources, and will be discarded when those resources are required to
recover the working traffic of a particular working LSP.)

The difference is that "extra-traffic" using protection resources _must_
have the same ingress-egress as the working path that the protection
resources
are reserved and cross-connected for.
(This is what allows for there to be "extra-traffic" even in the 1:1
protection
case, as you say below.)

"Extra-traffic" using restoration resources may, however, have _any_
ingress-egress,
as long as _some of the links_ on the path of the "extra-traffic" LSP share
some of the restoration resources reserved to recover a working path.

It seems to me that you are saying that for this second case, the reserved
(but not cross-connected) resources can be used by setting up low-priority
pre-emptible
LSPs. But, the use of these resources by such LSPs is something that is
_independent_
of the scope of the P&R effort, since it can (mostly) be accomplished by
existing
LSP setup mechanisms, and since the bandwidth reserved (but not cross
connected)
can (it appears) be advertized using standards GMPLS OSPF-TE. Yes?

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.

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

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

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.

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

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

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
>