Subject: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking

From: [email-masked]
Date: Tue, 24 Feb 2004 16:00:30 +0100

Hi all,

We have posted draft-ietf-nsis-qos-nslp-02.txt. The draft contains a number
of open issues for which feedback from the WG would be helpful. In order to
stimulate (and focus) discussion, I'll tackle the issues one by one in
separate threads. You may have seen in draft-ietf-nsis-qos-nslp-02.txt that
QSPEC objects may be stacked to allow aggregation and layering. In
error-free conditions, the top of the QSPEC stack has the QSPEC object that
is locally valid.

A QNE may receive a QoS NSLP message with a QSPEC stack of which the top
object is not recognised. This can occur under error conditions, e.g. when
a domain boundary is misconfigured, or it me be the result from a policy to
detect domain boundaries by encountering unrecognised QSPEC objects.

In some situations, a QNE may be able to recover from the error condition
by inspecting a larger portion of the stack. If and how a QNE should deal
with this is still an open issue in the draft. In order to resolve this
issue, the authors would like to pose the following questions to the
working group:

1. Should a QNE attempt to recover from an unrecognised QSPEC stack ...
      a. ... in addition to sending an error message upstream?
      b. ... instead of sending an error message upstream?
Suggestion: yes, in addition to sending an error

2. How far can a QNE inspect the QSPEC stack?
      a. only the next QSPEC
      b. the entire stack
This is essentially a trade-off between the amount and type of errors that
you want to recover from and the complexity. Suggestion is to allow
inspection of the entire stack in case the edge QNE is the same for several
layers.

3. What should be done with the stack when a deeper QSPEC is recognised
      a. leave intact
      b. discard all QSPECs above the recognised QSPEC
Suggestion: discard everything above. This avoids that all subsequent QNEs
need to do the same inspection.

Thanks for any comments on this.

Best regards,
Sven

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Cheng Hong" <[email-masked]>
Date: Wed, 25 Feb 2004 14:27:10 +0800

Hi Sven, and all,

Please see some comments below:

<snip>
> Suggestion: yes, in addition to sending an error

Does this also depend on what the error message contains and how the QNE
peer responds to the error message? If the error message would simply cause
the peer QNE to resend the entire QSPEC stack, would the recover still be
necessary? 

> This is essentially a trade-off between the amount and type 
> of errors that you want to recover from and the complexity. 
> Suggestion is to allow inspection of the entire stack in case 
> the edge QNE is the same for several layers.

Maybe this also depends on whether the recover is possible based on the next
QSPEC. If the recover isn't possible, i.e. whole stack of QSPEC needs to be
resent, there is no need to go any furhter. 

> Suggestion: discard everything above. This avoids that all 
> subsequent QNEs need to do the same inspection.

This is closely related to the point 2. Does this assume that there is no
more unrecognized QSPEC between the "deeper QSPEC" and the end of the stack?

Cheers

Cheng Hong