The MPLS WG Archive

[Adrian Farrel <adrian@olddog.co.uk>]

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