Subject: [ANCP] Another base protocol issue: Result Code semantics

From: Tom Taylor <[email-masked]>
Date: Fri, 3 Dec 2010 16:09:57 -0500

Matthew Bocci's review raised the issue of missing semantics for Result 
Code values. In response, I propose the following. Please provide any 
comments by next Wednesday, so I can get an updated document out by next 
Friday.

1. Add a general statement that any specification of a new Code value 
must follow this template:

Code value:
One-line description:
Where condition detected: (control application or ANCP protocol layer)
Further description (if any):
Required additional information in the response message:
Target: (control application or ANCP protocol layer at the peer that 
sent the original request)
Action required by the receiving ANCP protocol layer:

2. Add a general statement before the individual Code values as follows:

"In addition to any suggested action in the text which follows, the Code 
value SHOULD be logged in a MIB. Where an action includes resending of a 
request, a given request SHOULD NOT be resent more than once."

3. Make support of the Generic Response message and the Status-Info TLV 
mandatory for all ANCP implementations.

4. Modify the Generic Response message to require that besides the 
Status-Info TLV, it MUST contain any line-identifying TLVs present in 
the original request.

5. Revise the descriptions of the Code values already shown in Section 
4.6 to read as follows:

Code value: 2
  - One-line description: Invalid request message
  - Where condition detected: ANCP protocol layer
  - Further description: The request was a properly formed message which 
violates the protocol through its timing or direction of transmission. 
The most likely reason for this outcome in the field will be a race 
condition.
  - Required additional information in the response message: none, if 
the response message is of the same type as the request. As specified in 
Section <genResp> if the response message is a Generic Response message.
  - Target: ANCP protocol layer at the peer that sent the original request
  - Action required by the receiving ANCP protocol layer: The original 
request MAY be resent once only after a short delay. Inform the control 
application with appropriate identification of the failed transaction if 
the second attempt fails or no second attempt is made.

Code value: 3 or 81 (latter is preferred)
  - One-line description: Request message type not implemented
  - Where condition detected: ANCP protocol layer
  - Further description: This could indicate a mismatch in protocol 
version or capability state. It is also possible that support of a 
specific message is optional within some ANCP capability.
  - Required additional information in the response message: none, if 
the response message is of the same type as the request. As specified in 
Section <genResp> if the response message is a Generic Response message.
  - Target: ANCP protocol layer at the peer that sent the original request
  - Action required by the receiving ANCP protocol layer: If the 
receiver of this Code value expects that support of the message type 
concerned is mandatory according to the capabilities negotiated for the 
session, it SHOULD cause the adjacency for the partition to be reset and 
renegotiated by sending an adjacency message with pType = 0 and Code = 
RSTACK as described in Section 11.3 of RFC 3292.

Code value: 4 or 1280 (latter is preferred)
  - One-line description: One or more of the specified ports do not exist
  - Where condition detected: control application
  - Further description (if any): this may indicate a configuration 
mismatch between the AN and the NAS or AAA.
  - Required additional information in the response message: if the 
request identified multiple access lines or the response is a Generic 
Response message, then the response MUST contain a Status-Info TLV 
encapsulating TLV(s) containing the rejected line identifier(s).
  - Target: control application at the peer that sent the original request
  - Action required by the receiving ANCP protocol layer: indicate the 
error and forward the line identifiers to the control application.

Code value: 6
  - One-line description: One or more of the specified ports are down
  - Where condition detected: control application
  - Further description (if any):  This Code value indicates a state 
mismatch between the NAS and AN control applications, possibly due to a 
race condition.
  - Required additional information in the response message: if the 
request identified multiple access lines or the response is a Generic 
Response message, then the response MUST contain a Status-Info TLV 
encapsulating TLV(s) containing the line identifier(s) of the access 
lines that are not operational.
  - Target: control application at the peer that sent the original request
  - Action required by the receiving ANCP protocol layer: indicate the 
error and forward the line identifiers to the control application.

Code value: 7
  – One-line description: Invalid Partition ID
  - Where condition detected: ANCP protocol layer
  - Further description: This indicates that the request used a 
Partition ID value different from what was determined for this partition 
during adjacency negotiation, implying a state mismatch between the ANCP 
protocol implementations.
  - Required additional information in the response message:  none, if 
the response message is of the same type as the request. As specified in 
Section <genResp> if the response message is a Generic Response message.
  - Target: ANCP protocol layer at the peer that sent the original request
  - Action required by the receiving ANCP protocol layer: If multiple 
instances of this error occur, the requestor SHOULD cause the adjacency 
for the partition to be reset and renegotiated by sending an adjacency 
message with pType = 0 and Code = RSTACK as described in Section 11.3 of 
RFC 3292.

    NOTE: This specification provides no way for the NAS to do
    a complete audit of the current state stored on the AN. Hence
    renegotiation of the adjacency with pFlag = 2 (connection state
    retained at the AN) MAY be attempted, but entails some risk of
    state mismatch.

Code value: 19
  - One-line description: Out of resources
  - Where condition detected: ANCP protocol layer or control application
  - Further description: (e.g., memory exhausted, etc.). This Code value 
MUST be reported by the AN only, and indicates a condition that is 
probably unrelated to specific access lines (although it may be related 
to the specific request).
  - Required additional information in the response message:  none, if 
the response message is of the same type as the request. As specified in 
Section <genResp> if the response message is a Generic Response message.
  - Target: ANCP protocol layer at the peer that sent the original request
  - Action required by the receiving ANCP protocol layer: If the NAS 
receives this Code value from multiple requests for the same AN in a 
short interval, it SHOULD reduce the rate at which it sends requests in 
proportion to the rate at which requests are failing with Code = 19.
It MAY retry individual requests. If only a specific request is failing 
with Code = 19, the ANCP protocol layer in the NAS MAY request the 
control application to decompose the request into simpler components if 
this is possible.

Code value: 30
  - One-line description: The limit on the maximum number of 
point-to-multipoint connections that the switch can support has been reached
  - Where condition detected: AN control application
  - Further description: This condition is multicast-related, and is 
thus out of scope of the current document but within the scope of 
multicast-related extensions to the ANCP protocol.
  - Required additional information in the response message:  none, if 
the response message is of the same type as the request. As specified in 
Section <genResp> if the response message is a Generic Response message.
  - Target: NAS control application
  - Action required by the receiving ANCP protocol layer: indicate the 
error and forward details identifying the original request to the NAS 
control application.

Code value: 31
  - One-line description: The limit on the maximum number of branches 
that the specified point-to-multipoint connection can support has been 
reached
  - Where condition detected: AN control application
  - Further description: This condition is multicast-related, and is 
thus out of scope of the current document but within the scope of 
multicast-related extensions to the ANCP protocol.
  - Required additional information in the response message:  none, if 
the response message is of the same type as the request. As specified in 
Section <genResp> if the response message is a Generic Response message.
  - Target: NAS control application
  - Action required by the receiving ANCP protocol layer: indicate the 
error and forward details identifying the original request to the NAS 
control application.

Code value: 83
  - One-line description: Malformed message
  - Where condition detected: ANCP protocol layer
  - Further description: This could be the result of corruption in 
transit, or an error in implementation at one end or the other.
  - Required additional information in the response message:  none, if 
the response message is of the same type as the request. As specified in 
Section <genResp> if the response message is a Generic Response message.
  - Target: ANCP protocol layer at the peer that sent the original request
  - Action required by the receiving ANCP protocol layer: The request 
SHOULD be resent once to eliminate the possibility of in-transit corruption.

Code value: 84
  - One-line description: Mandatory TLV missing
  - Where condition detected: ANCP protocol layer
  - Further description: none.
  - Required additional information in the response message: the 
response message MUST contain a Status-Info message that encapsulates an 
instance of each missing mandatory TLV, where the length is set to zero 
and the value field is empty (i.e., only the four-byte TLV header is 
present).
  - Target: ANCP protocol layer at the peer that sent the original request
  - Action required by the receiving ANCP protocol layer: resend the 
message with the missing TLV(s), if possible. Otherwise, report the 
error to the control application with an indication of the missing 
information required to construct the missing TLV(s).

Code value: 85
  - One-line description: Invalid TLV contents
  - Where condition detected: ANCP protocol layer
  - Further description: the contents of one or more TLVs in the request 
do not match the specifications provided for the those TLVs. (Errors of 
this type SHOULD be caught before the request is sent in the first 
place, through ANCP protocol layer validation of the input from the 
control application.)
  - Required additional information in the response message: the 
response MUST contain a Status-Info TLV encapsulating the erroneous TLVs 
copied from the original request.
  - Target: ANCP protocol layer at the peer that sent the original request
  - Action required by the receiving ANCP protocol layer: correct the 
error and resend the request, if possible.  Otherwise, report the error 
to the control application with an indication of the erroneous 
informationassociated with the invalid TLV(s).

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Tue, 21 Dec 2010 11:07:52 +0100

Hi Tom,

Thank you for detail these. In general, I am fine with the proposal, but I
think the actions are SHOULDs rather than required.

Regards

Matthew

>request, a given request SHOULD NOT be resent more than once."

If this is the case, then in general you don't need to say '

>   One-line description: Invalid Partition ID
>_______________________________________________
>ANCP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ancp