Subject: draft-meyer-soft-preemption-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Mar 2003 03:38:02 -0500

Hi,

I support this concept, but I wonder why you do not use PathErr instead of Resv.
Why not just define a new Errcode/value for the PathErr to indicate preempted
but still in place?
Transit nodes (including backwards compatibility) will forward the PathErr but
not act on the LSP
The headend can treat the PathErr as you describe by performing
make-before-break.

Cheers,
Adrian

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 Mar 2003 13:01:16 -0500

In message <[email-masked]>, "Adrian Farrel" writes:
>  
> Hi,
>  
> I support this concept, but I wonder why you do not use PathErr
> instead of Resv .  Why not just define a new Errcode/value for the
> PathErr to indicate preempted but still in place?  Transit nodes
> (including backwards compatibility) will forward the PathErr but not
> act on the LSP The headend can treat the PathErr as you describe by
> performing make-before-break.
>  
> Cheers,
> Adrian

The current semantics of path-err or path-tear is to indicate an error
in setup or to tear down.  Any intermediate node that didn' understand
this would release resources and cause traffic to black hole, exactly
what the soft preempt is trying to avoid.

The soft preempt is an advisory from a midpoint to the ingress that
while an LSP is up, its resource reservation cannot be maintained and
it must be voluntarily rerouted or face tear down.  A bit in the
normal resv is a better way to express this than one of the error or
explicit tear down mechanisms.

Also, any midpoint that recieves this and then has to do a preempt can
prefer to soft preempt an already soft preempted LSP over one that has
not yet been preempted.  This would be quite common during the
reaction to a link failure, if the rerouting of preferred LSPs caused
less preferred LSPs to be preempted.

Curtis

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Mar 2003 13:23:24 -0500

Curtis,

> what the soft preempt is trying to avoid.

Interesting, but I don't believe this is the semantics of a PathErr. In fact,
quite to the contrary. This is why RFC3473 introduces the Path_state_removed
flag.

To quote from RFC3473 section 4.4
   The PathErr message as defined in [RFC2205] is sent hop-by-hop to the
   source of the associated Path message.  Intermediate nodes may
   inspect this message, but take no [sic] action upon it.

That is: the existing PathErr preemption scheme is *already* soft with two
exceptions...
- the preempting node currently releases the resources of the LSP
   (this is local behavior and can be modified by implementations)
- the ingress node currently sends PathTear
   (this is local behavior and can be modified by implementations)

We might want to add further local behavior to "allow" a transit node to inspect
and act on a preemption PathErr.

None of these changes speak to the need for a signaling change, but it might be
useful to indicate how the preempting node has behaved.

> explicit tear down mechanisms.

I disagree as above because PathErr is not an explicit tear down mechanism.

> less preferred LSPs to be preempted.

I believe this is facilitated equally by a PathErr.

Thanks,
Adrian

---

From: George Swallow <[email-masked]>
Date: Mon, 17 Mar 2003 13:21:54 -0500

> The headend can treat the PathErr as you describe by performing

There is one difference.  In 2205 the RESV is sent reliably
(periodically refreshed) and the PathErr is one shot.  However if
you're using 2961, this argument goes away.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: George Swallow <[email-masked]>
Date: Mon, 17 Mar 2003 14:21:46 -0500

Curtis -

> what the soft preempt is trying to avoid.

If that were true for path-err, why does path-err have an in-place bit
to express that the reservation is still there?

...George

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 Mar 2003 15:10:05 -0500

> to express that the reservation is still there?

Expect that a certain implementation that we need to take into
consideration tears down if it doesn't understand the error code.

It also gets upset if it doesn't understand bits in the 'RRO IPv4/IPv6
Sub-Object Flags' or 'SESSION-ATTRIBUTES Flag' so that doesn't help
with either RRO flags or path-err.  At least the SESSION-ATTRIBUTES
flag will yield a path-err on the initial setup and the ingress can
fall back to a setup with no soft-preempt requested.

If the ingress doesn't understand soft-preempt, no sense sending it,
since it just delays the inevitable preempt.  If the midpoints will
tear down immediately due to an unknown error code or an unknown RRO
flag bit, its good to know that too.

The preference for the RRO flag is that like the protect-inuse, the
ingress knows which hops it does not have resources on.  Consider the
path A-B-C-...Z.  If hops D-E and G-H have preempted, but all of the
hops are near 100% utilized, the ingress knows it can share bandwidth
with its prior LSP on all hops for which the RRO flag bit is not set.
Its harder to do that with a collection of path-err messages.

Also, I haven't mentioned to the list, but if you put the preempted
bit back in the PATH ERO, others downstream of the initial
soft-preempt can soft-preempt the same LSP during the time that it
reroutes.  If we are looking for sub-second convergence plus
soft-preempt, this could be a very valuable feature.  The bit change
in the ERO is purely advisory and requires no change in resource
allocation so it can be propogated very quickly, much more quickly
than CSPF plus path setup.

Another reason to put this in the RRO is if FRR is used, the LSP is
both soft-preempted and protect-inuse must be set.  It is better to
set two bits in the RRO rather than send two separate messages.  If
the backup got preempted, then soft-preempt set and local-protect
available cleared would have a higher sense of urgency than
soft-preempt set and local-protect inuse being set.

I've given a few advantages of putting this in RRO.  What are the
technical advantages of putting this in path-err?

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 Mar 2003 15:16:32 -0500

> you're using 2961, this argument goes away.

In 2961, all it says about path-err is "PathErr and ResvErr messages
SHOULD be treated as implicit acknowledgments".  They are still one
shots.

If anything, if drops do occur, fast RESV propogation is more likely
with RFC2961 but path-err reliability is not improved.

Curtis

---

From: George Swallow <[email-masked]>
Date: Mon, 17 Mar 2003 16:43:37 -0500

Curtis -

 From RFC2961:

4.5. MESSAGE_ID Object Usage

    The MESSAGE_ID object may be included in any RSVP message other than
    the Ack and Bundle messages.  The MESSAGE_ID object is always
    generated and processed over a single hop between RSVP neighbors.

So you can use 2961 for reliable delivery of a Path_Err.

...George

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 Mar 2003 16:54:04 -0500

In message <[email-masked]>, Curtis Villamizar 
> than CSPF plus path setup.

Pavan Beeram pointed out that this could go in the PATH RRO and be
sent directly by the midpoint at the time of failure to indicate to
the downstreams that an soft-preempt was pending and increasing the
chance of preempting the same LSP rather than a different one.

Curtis

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Mon, 17 Mar 2003 23:46:04 -0800

Hi Curtis,

>Its harder to do that with a collection of path-err messages.

That's perfectly correct and one of the reasons why we ended up with this 
scheme. Otherwise, the HE would have had to wait for some unknown period of 
time (to make sure it has received all the PERR from the set of preempting 
nodes) before triggering a new CSPF on the modified topology

>soft-preempt set and local-protect inuse being set.

Fully agree.

Will add another one: the number of signalling messages when the preempted 
TE LSP is soft preempted at multiple hops ...

This only drawback with the Resv RRO message would be the existence of mid 
point LSRs non supporting the soft preemption draft as they might no detect 
the Resv message change (RRO preemption pending bit set) and as such would 
not trigger an immediate refresh. This would introduce some delay in the HE 
notification.

JP.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 18 Mar 2003 10:29:58 -0500

In message <[email-masked]>, Jean Philippe V
> not trigger an immediate refresh. This would introduce some delay in the HE 

Our RSVP guys tell me the same LSR we are both concerned about that is
blind to RRO changes such as local-protect-inuse also barfs on unknown
bits in the session object so if one of them was in the path the
initial PATH message would have to remove the request for
soft-preemption to get the LSP to come up in the first place.  So this
would work for LSR software in the field and just work better when
that software is upgraded.

This brings to mind two useful changes to RFC3209 or another document
could be written and later merged in.  Either the semantics of the
SESSION-ATTRIBUTES Flags should have a note that unknown bits should
be ignored.  In the description of the RRO, a note should be made that
an LSR must pass on changes to the IPv4/IPv6 flags immediately and
must ignore flags that are not understood.  A small section could be
added giving guidelines for well written extensions.  These would have
a request bit in the SESSION-ATTRIBUTES Flags, a capabilities bit in
the RRO IPv4 or IPv6 flags, and if needed one or more status bit (such as
available and inuse for local-protect, or pending for soft-preempt).

I would hope that extensions would be rare and if proved useful would
be folded into an update to RFC3209.  Extensions have to be rare
because we only have 8 bits available so we should be choosey.  I
think soft preempt is a valuable extension.  Its need has been stated
by ISPs and its need has been proven in practice. (more than one has brought this up, but not on the list, the
author of this document is from GX though, so this is from an SP)

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 18 Mar 2003 10:36:55 -0500

It would be easiest to write an extensions mechanism draft and then
fold it into RFC3209 later.  If we were worried about too few bits
(and I'd prefer we didn't go this route) we could add an extension
request object with a 32 bit flag, and a 32 bit extension capabilities
and flags subobject to RRO.  I'd prefer keeping the number of
extension to mimimum and only doing things with very clear benefits.

I would hope that extensions would be rare and if proved useful would
be folded into an update to RFC3209.  Extensions have to be rare
because we only have 8 bits available so we should be choosey.  I
think soft preempt is a valuable extension.  Its need has been stated
by ISPs and its need has been proven in practice.  More than one has
brought this up, but not on the list, the author of this document is
from GX though, so this is from an SP.

Curtis

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Mar 2003 11:55:28 -0500

The preference for the RRO flag is that like the protect-inuse, the
    ingress knows which hops it does not have resources on.  Consider the path A-B-C-...Z.  If hops D-E and G-H have preempted, but all of the hops are near 100% utilized, the ingress knows it can share bandwidth with its prior LSP on all hops for which the RRO flag bit is not set. Its harder to do that with a collection of path-err messages.

  That's perfectly correct and one of the reasons why we ended up with this scheme. Otherwise, the HE would have had to wait for some unknown period of time (to make sure it has received all the PERR from the set of preempting nodes) before triggering a new CSPF on the modified topology 

OK. But I don't see how using Resv lets you know when all of the premption is complete. Since in your example preemption of D-E is likely to happen first it will  trigger a Resv reporting just one hop as preempted. Later there will be another Resv that indicates D-E and G-H as preempted. Sometime later there might be another Resv indicating further preemption down near Z. 
The only advantage seems to be that the Resv gives you a list of preemptions that have happened (saving the HE from having to maintain that list itself). It does not remove the "unknown period of time" issue.

This is a good reason for a flag in the ERO. It doesn't speak to the use of Resv at all.

  Will add another one: the number of signalling messages when the preempted TE LSP is soft preempted at multiple hops ...
As in the example above, you still get multiple messages (don't you?).
  This only drawback with the Resv RRO message would be the existence of mid point LSRs non supporting the soft preemption draft as they might no detect the Resv message change (RRO preemption pending bit set) and as such would not trigger an immediate refresh. This would introduce some delay in the HE notification.
Are you sure there are no implementations out there that will tear down the LSP because of an unrecognized flag in the RRO? :-)

Adrian

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 18 Mar 2003 12:34:42 -0500

In message <[email-masked]>, "Adrian Farrel" writes:
> 
> Are you sure there are no implementations out there that will tear down =
> the LSP because of an unrecognized flag in the RRO? :-)
> 
> Adrian

Based on our experience with the local-protect bits, there is an
implementation out there that we know will tear down the LSP because
of an unrecognized flag in the RRO but that same implementation will
send a path-err when it doesn't recongnize the capability request bits
in the session attributes flags so soft-preempt will be disabled.

Curtis