The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <036001c4374a$be894030$67849ed9@Puppy>, "Adrian Farrel" writes:
> Hi,
> 
> A certain feeling of deja lu.
> 
> Cutting straight to Curtis' comments...
> 
> > But you may not want to rely on this behaviour (or implement it for
> > that matter since it holds onto resources that just lead to a
> > blackhole downstream) because some vendors believe that the
> > microflow-RSVP behaviour above does not apply to RSVP-TE and many
> > routers in the field discard forwarding state on RSVP-TE path-err,
> > regardless of how many times a few people on this list cite the
> > reference.
> 
> Right!
> 
> I think we arrived at this conclusion as a WG in around December last year.
> 1. We acknowledged that there are two interpretations.
> 2. We decided that there is zero value in arguing about the 
>     'right' interpretation.
> 3. We agreed that there is a significant weight of deployed code.
> 4. We were concerned that new implementations must be 
>     given enough information that thay can achieve interoperability
>     without requiring reverse engineering or attendance at 
>     interop events.
> 5. We agreed that there is a requirement for both soft and hard
>     preemption.
> 6. We were looking for a solution that
>     a. documented more clearly the expected behavior of a 3209-
>         conformant implementation
>     b. allowed soft and hard pre-emption to be achieved without
>         substantial modification to code structure.
>     c. was extensible to GMPLS without requiring a change to the
>         procedures described in 3473.
> 
> For point 6, I think there are two proposals on the table.
> 
> A.  A BCP or clarification of 3209 and 3473
>       draft-ietf-mpls-soft-preemption-02.txt
> or
> B.  draft-farrel-mpls-preemption-01.txt
> 
> Adrian


Adrian,

Thank you for clarifying my perhaps too terse comments.

In terms of what to do, draft-farrel-mpls-preemption-01.txt does not
have the capability to probe for soft preemption capability along the
path.  If the preempting router and the ingress support this
mechanism, but an older router is in the path, resources will be torn
down along the path and the ingress may not be aware of it.

With draft-ietf-mpls-soft-preemption-02.txt if a router along the path
does not suuport this functionality it should pass along the flags
change and do nothing.  The ingress and the preempting router are the
only two along the path that must understand this extension.  In
addition, reroute is never immediate (it always takes a finite time).
Other routers are aware of LSP that pass through that have already
been preempted elsewhere and can preempt those as opposed to another.
In addition, the preempting router knows whether the ingress supports
soft preemption and can hard preempt if it does not.

Another difference between the two is one is a WG draft and the other
is not.

You do make a good point that draft-ietf-mpls-soft-preemption-02.txt
or some other draft should include a clarification of the 3209 and
3473 sections.

Curtis