Subject: [ANCP] Question about Multicast Status Message in draft-ietf-ancp-mc-extensions-00

From: Fortune HUANG <[email-masked]>
Date: Tue, 18 Aug 2009 17:40:25 +0800

Hi all,
 
I am puzzled about using Multicast Status Message for failed response in
many different procedures (e.g. Delegated Bandwidth Query, Multicast Flow
Query) in draft-ietf-ancp-mc-extensions-00.
 
Take the Delegated Bandwidth Query procedure in section 4.8 for example.
Three messages are involved in this procedure.
 
1) Delegated Bandwidth Query Request
2) Delegated Bandwidth Query Response: used as a successful response, Result
field always Success (0x3) 
3) Multicast Status Message: used as a failed response
 
I am wondering why we can not allow the Result field to be set other values
than Success (0x3), e.g.  Failure (0x4).
In fact, I think we can use Delegated Bandwidth Query Response for both the
successful and failed cases if we don't force to Result field to be always
Success (0x3).  Then only two messages are involved in the Delegated
Bandwidth Query procedure:
 
1) Delegated Bandwidth Query Request
2) Delegated Bandwidth Query Response: Result field Success (0x3) for
successful case, Result field Failure (0x4) for failed case
 
As far as I know, TLVs could be optional. The message sender can decide
which TLVs should be included in the message in different cases. If you look
at Diameter protocol, it is just like this. So I think it would be more
reasonable using one message for the response no matter it is a successful
or failed response. That is also why we need a Result field in the response
message.

Best regards,
Fortune

---

From: Tom Taylor <[email-masked]>
Date: Tue, 18 Aug 2009 11:03:41 -0400

I have an action item to redefine the Multicast Status message as a message 
(say, Status) supported by the base protocol. I'm ready to start working on 
that, except that you are raising a possible alternative that needs discussion.

Let me generalize the question you are raising. You point out that the current 
text provides for two possible responses to a Delegated Bandwidth Query message: 
a Delegated Bandwidth Response, or a Multicast Status message. This alternative 
actually applies to most of the messages defined for ANCP, since the possible 
status codes (shorthand for Result Code within the Status-Info field) in the 
Multicast Status message include some very general error cases. I assume your 
concerns are:
  - having to watch for two different responses complicates the original 
sender's state machine;
  - the sender has to correlate the [Multicast] Status message with the original 
message.

The alternative you suggest is that the response always matches the request. It 
seems to me this implies that in the case of failures the response has to 
contain a Status-Info field. This should be specified as a basic feature of the 
protocol (i.e. in the base protocol specification).

We can define some exceptions where an independent Status message is needed, if 
the condition being identified is independent of a specific request. So I'll 
work on my text proposal for a base-level Status message. But could we have 
comments on the proposal to replace Status with a failed response to the 
original request as the normal error response??

Tom Taylor

Fortune HUANG wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp