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

[Tom Taylor <tom.taylor at rogers.com>]

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:
> 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
>  
>   
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ANCP mailing list
> ANCP at ietf.org
> https://www.ietf.org/mailman/listinfo/ancp