The MPLS WG Archive

["Adrian Farrel" <afarrel@movaz.com>]

Re-send: Doesn't appear to have hit the list.

Adrian
----- Original Message -----
From: "Adrian Farrel" <afarrel@movaz.com>
To: "Ina Minei" <ina@juniper.net>
Cc: <mrm@gblx.net>; <denver@gblx.net>; <jpv@cisco.com>; "'mpls@uu.net'"
<mpls@UU.NET>
Sent: Thursday, May 22, 2003 3:23 PM
Subject: Re: draft-ietf-mpls-soft-preemption-00


> Hi Ina,
>
> Thanks for engaging.
>
> > As far as I can see, the two issues raised are:
> > 1) the need for the soft-preemption draft
> > 2) the use of the rro mechanism rather than a path error for the
> > notifications.
> >
> > I will address them separately below.
>
> That's fine.
> I am trying to discuss only issue 1).
> I have strong feelings about the use of the RRO for this proposal, but I don't
> want to get into them at this stage.
>
> > 1) The need for soft-preemption
> > I agree that 3209 doesn't explicitly specify that the
> > preempted lsp should be torn down. However, rfc 2702, when discussing the
> > preemption attribute makes it clear that preemption is there to accomodate
> > the case where there are not enough resources to share, and overbooking is
> > not mentioned. Thinking of the goal that preemption is trying to achieve,
> > it seems reasonable that immediate teardown would be performed.
>
> I think this depends radically on the network type. In an optical network, for
> example, it is wholly reasonable to say that preemption of a resource at a
> particular node breaks the LSP. That is, if I take the laser and use it for
> something else, then traffic on the old LSP stops flowing. This also probably
> causes alarms.
>
> Depending on the way that this intercepted resource is used, the downstream
LSP
> may need to be torn (to prevent data being sent to the wrong place).
> If the LSP is bidirectional, the upstream LSP may also need to be torn.
> There is a facility for both of these options (PathTear and PathErr with state
> removal).
>
> On the other hand in some optical networks, it will be highly desirable to
avoid
> resource churn by leaving the most of the LPS in place and treating the
> preemption just like an alarm or a resource failure. The ingress (or some
other
> repair point) can use make before break to repair around the error without
> deprovisioning and reprovisioning at all of the other nodes.
>
> Now, in a packet network, we can add to this list the facility for
> over-provisioniing and handling traffic as best effort.  In these cases the
most
> that happens is that the LSP is degraded. The level of this degradation is on
a
> scale from total (as in the optical network) to none, when the traffic on
other
> resource users is low. If there is ever the cahnce of passing traffic, it
seems
> best to do so. This will show less impact for the customer.
>
> > In any case, I think a specification is necessary for
> > soft-preemption. I also believe there is value in allowing the user to
> > specify whether soft preemption is desired or not on a per-lsp basis
>
> I have no issue with this. The change, however, is one of semantics. That is,
if
> you want *hard* preemption to occur at the preempting node (i.e. LSP teardown
to
> begin at the preempting node) this will require a new session attribute. As I
> hope I made clear, my opinion is that preemption is already soft by default.
>
> > and
> > how long the overbooking may be maintained.
>
> This is not an issue for the preempting node to manage on behalf of the
ingress.
> Rather, it is an issue for the ingress to manage for the LSP, and the
preempting
> node to manage on its own behalf.
>
> You would be better to have the preempted node report the time for which it
will
> continue to allow over subscription when it reports the preemption.
>
>
> Anyway, nothing I have been shown, RFC2702 notwithstanding, suggests to me
other
> than the current correct behavior of upstream nodes receiving a PathErr
> reporting preemption is to keep the LSP in place. This is why the state
removal
> flag was introduced to the PathErr.
>
>
> Cheers,
> Adrian
>
>
> >
> > 2) The use of rro vs path error
> > The original proposal for this draft was to use a path-error
> > message (and allocate a new notify-error subcode), just like you propose.
> > A few private and  public discussions on this topic took place. There are
> > pros/cons to both approaches, and the authors decided to pick the rro
> > solution.
> >
> > Ina
> >
> > On Mon, 19 May 2003, Adrian Farrel wrote:
> >
> > > Hi,
> > >
> > > I still have a concern about this draft. My understanding of the existing
> RFCs
> > > is that the soft-preemption behavior that you want is what is already
> specified.
> > > There is, perhaps, an issue that the error code used for preemption is not
> well
> > > specified in RFC3209.
> > >
> > > I'd appreciate your thoughts.
> > > Thanks,
> > > Adrian
> > >
> > > =========
> > >
> > > In the Abstract you say
> > > "Under present RSVP-TE signaling methods, LSPs are immediately displaced
> upon
> > > preemption."
> > >
> > > and in section 2, Motivation, you have
> > > "Present MPLS RSVP-TE implementations only support a method of TE LSP
> > > preemption which immediately tears down TE LSPs, disregarding the
> > > preempted in-transit traffic, in an effort to make way for a higher
> > > priority TE LSP if not enough bandwidth is available on the link to
> > > accommodate the newly signaled high priority TE LSPs.  This process
> > > nearly guarantees preempted traffic will be discarded, if only briefly,
> > > until the RSVP Path Error message reaches and is processed by the
> > > head-end (HE) and a new forwarding path can be established."
> > >
> > > I disagree with your interpretation of RFC3209.
> > >
> > > Section 4.7.3 has
> > > " When preemption is supported, each preempted reservation triggers a
> > >    TC_Preempt() upcall to local clients, passing a subcode that
> > >    indicates the reason.  A ResvErr and/or PathErr with the code "Policy
> > >    Control failure" SHOULD be sent toward the downstream receivers and
> > >    upstream senders."
> > >
> > > I'm inclined to agree with what George said in SF: this is a hole in
> RFC3209.
> > > If we turn to RFC2205 for a definition of Policy Control Failure we find
in
> > > Appendix B...
> > > "   o    Error Code = 02: Policy Control failure
> > >
> > >         Reservation or path message has been rejected for administrative
> > >         reasons, for example, required credentials not submitted,
> > >         insufficient quota or balance, or administrative preemption.
> > >         This Error Code may appear in a PathErr or ResvErr message.
> > >
> > >         Contents of the Error Value field are to be determined in the
> > >         future."
> > >
> > > Nowhere here do I see anything that says that the LSP is torn down, but
> rather
> > > that the traffic becomes best effort (which is what you want in your
draft).
> > > Perhaps the main issue is that nearly all the references to PathErr in
> RFC3209
> > > relate to errors during the LSP setup procedure. But surely PathErr
messages
> > > that happen after the LSP has been established inherit their behavior from
> > > RFC2205 if there is nothing else described in RFC3209.
> > >
> > > Section 3.5 or RFC2205 says
> > > "     There are two RSVP error messages, ResvErr and PathErr.  PathErr
> > >       messages are very simple; they are simply sent upstream to the
> > >       sender that created the error, and they do not change path state
> > >       in the nodes though which they pass.  There are only a few
> > >       possible causes of path errors."
> > >
> > >
> > > Note that there is already a suitable error code defined in RFC 2205.
> > >
> > > "  o    Error Code = 12: Service preempted
> > >
> > >         The service request defined by the STYLE object and the flow
> > >         descriptor has been administratively preempted.
> > >
> > >         For this Error Code, the 16 bits of the Error Value field are:
> > >            ssur cccc cccc cccc
> > >
> > >         Here the high-order bits ssur are as defined under Error Code
> > >         01.  The globally-defined sub-codes that may appear in the low-
> > >         order 12 bits when ssur = 0000 are to be defined in the future."
> > >
> > > This tends to imply that the Error Code is only available for use on a
> ResvErr
> > > (since that is where the flow descriptor is).
> > >
> > > Alternatively, you could either define a new Error Value for the "Policy
> Control
> > > failure" Error Code, or perhaps you would rather move the condition to the
> > > "Notify" Error Code.  For consistency, one might assign the new Error
Value
> > > using the ssur cccc cccc cccc format, setting the u-bit to 1 to show that
> this
> > > represents a state update that should be passed onwards, although RFC3209
> > > doesn't bother with the u-bit and says
> > > "   For the Notify Error Code, the 16 bits of the Error Value field are:
> > >          ss00 cccc cccc cccc"
>
>