RE: New draft on Extra class LSP

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

Hi Dimitri,

Thanks for the quick response. 

Pl. see some more comments in-line.

-Vishal

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Thursday, July 03, 2003 3:13 PM
> 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 in-line...
> 
> Vishal Sharma wrote:
> > Hi Dimitri,
> > 
> > 
> >>-----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
> >>
> >>
> >>hi adrian, kohei,
> >>
> >>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")
> > 
> > 
> > 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.* 

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.

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


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