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