Subject: Re: [ANCP] Changes to ANCP multicast

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 8 Oct 2009 16:54:02 +0200

including the ANCP list as others may be interested.
Francois

On 8 Oct 2009, at 16:53, Francois Le Faucheur wrote:

> Hi Tom,
>
> One question to better understand your proposal:
> In http://www.ietf.org/mail-archive/web/ancp/current/msg00955.html  
> you said:
> "Given that that Command TLVs will be present only in a limited set  
> of message types, and "Cmnd Nmbr" is not one of the fields defined  
> within the Command TLV, I would also remove "Cmnd Nmbr" from Status- 
> Info. It can always be specified as part of the failureresponse to a  
> particular message type."
>
> I am not sure how to read that.
> Are you saying that the Cmnd Nb would not appear in the Generic  
> Response message because if it is needed we woudl use a more  
> specific Response message?
> For the case of a negative response to a Multicast Replication  
> Control message: are you proposing that the Generic Response message  
> be used (and then would it not have to contain the "Cmnd Nb") or are  
> you saying that we would then use a new "Multicast Replication  
> Control Response" which woudl contain the Cmnd Nb?
>
> Thanks
>
> francois
>
>
> On 6 Oct 2009, at 17:15, Tom Taylor wrote:
>
>> I'm very happy to do that. Then we can discuss the result.
>>
>> Maglione Roberta wrote:
>>> Hello Tom,
>>>       in my opinion instead of submitting a new individual draft  
>>> you should update the current mcast draft and propose your changes  
>>> as a new version of the draft:
>>> draft-ietf-ancp-mc-extensions-01
>>> Meanwhile I can update the protocol draft with the additional  
>>> changes that you proposed.
>>> Best Regards,
>>> Roberta
>>> -----Original Message-----
>>> From: Tom Taylor [mailto:[email-masked]]
>>> Sent: Tuesday, October 06, 2009 4:57 PM
>>> To: Francois Le Faucheur IMAP; Maglione Roberta; Wojciech Dec
>>> Subject: Changes to ANCP multicast
>>> I made some major proposals regarding the ANCP protocol drafts at  
>>> the end of
>>> August but have had no feedback. I'm wodering if the best way  
>>> forward, given all
>>> I have in mind, is to submit a new draft-taylor-ancp-mc-extensions  
>>> incorporating
>>> all my proposals, to serve as a basis for discussion that people  
>>> can relate to.
>>> What are your views?
>>> Tom
>>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente  
>>> alle persone indicate. La diffusione, copia o qualsiasi altra  
>>> azione derivante dalla conoscenza di queste informazioni sono  
>>> rigorosamente vietate. Qualora abbiate ricevuto questo documento  
>>> per errore siete cortesemente pregati di darne immediata  
>>> comunicazione al mittente e di provvedere alla sua distruzione,  
>>> Grazie.
>>> This e-mail and any attachments is confidential and may contain  
>>> privileged information intended for the addressee(s) only.  
>>> Dissemination, copying, printing or use by anybody else is  
>>> unauthorised. If you are not the intended recipient, please delete  
>>> this message and any attachments and advise the sender by return e- 
>>> mail, Thanks.
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 9 Oct 2009 14:32:56 +0200

Tom,

On 9 Oct 2009, at 13:53, Tom Taylor wrote:

> Please see below.
>
> Francois Le Faucheur wrote:
>>> "Given that that Command TLVs will be present only in a limited  
>>> set of message types, and "Cmnd Nmbr" is not one of the fields  
>>> defined within the Command TLV, I would also remove "Cmnd Nmbr"  
>>> from Status-Info. It can always be specified as part of the  
>>> failureresponse to a particular message type."
>>>
> [PTT]
> Yes, that's what I had in mind.
>
>>> Control message: are you proposing that the Generic Response  
>>> message be used (and then would it not have to contain the "Cmnd  
>>> Nb") or are you saying that we would then use a new "Multicast  
>>> Replication Control Response" which woudl contain the Cmnd Nb?
> [PTT]
> I would recommend a response specific to Multicast Replication  
> Control.

This seems in contradiction with your Email of 27/08/2009 which says:
* Change "Multicast Status" to "Generic Response".
* "I assume the text should really read that the receiver MUST send a  
Generic Response message with the appropriate contents if unable to  
execute the complete Multicast Replication Control message  
successfully."

So, I am a little confused, now.

Currently, the Multicast Status message can be used in many scenarios  
including in responses to:
	* Multicast REplication Control request
	* Admission Control message
	* Bandwidth Reallocation
  	* Delegated Bw Query Request
	* Multicast Flow Query

Could you recap briefly what message you are proposing be used instead  
in each of these cases?

I can see that it would make sense to have a Generic Response message  
to deal with a number of generic cases (such as when a message is not  
recognized, or invalid).

Other than that, the MUlticast Status message was pretty much used as  
a multi-purpose response already (only, limited to all multicast use  
cases).

Thanks

Francois

> However, my E-mail of 27/08/2009 suggested adding a new sub-TLV to  
> Status-Info. To quote from the earlier message:
>
> *** command error
> -- Needs a new Code value, so add
>
> 85    Command error
>
> to base, and define in base a sub-TLV of Status-info to carry the  
> sequence number of the command within the message. This sub-TLV  
> could also carry an additional diagnostic code with its own IANA  
> registry if people think it might be useful. Extensions would define  
> the actual code values and add them to the registry. Likely  
> candidates are some of the errors listed in section 4.4:
>
> - Command not supported
>
> - Flag set but not supported
>
> - M Flag set, but no IP Source address provided
>
> - Unsupported Address Family
>
> - Unsupported address encoding
>
> - Malformed flow address
>
> - Multicast flow does not exist
>
>
>>>
>>> Thanks
>>>
>>> francois
>>>
>>>
>>>>> you should update the current mcast draft and propose your  
>>>>> changes as a new version of the draft:
>>>>> I made some major proposals regarding the ANCP protocol drafts  
>>>>> at the end of
>>>>> I have in mind, is to submit a new draft-taylor-ancp-mc- 
>>>>> extensions incorporating
>>>>> Questo messaggio e i suoi allegati sono indirizzati  
>>>>> esclusivamente alle persone indicate. La diffusione, copia o  
>>>>> qualsiasi altra azione derivante dalla conoscenza di queste  
>>>>> informazioni sono rigorosamente vietate. Qualora abbiate  
>>>>> ricevuto questo documento per errore siete cortesemente pregati  
>>>>> di darne immediata comunicazione al mittente e di provvedere  
>>>>> alla sua distruzione, Grazie.
>>>>> unauthorised. If you are not the intended recipient, please  
>>>>> delete this message and any attachments and advise the sender by  
>>>>> return e-mail, Thanks.
>>>

---

From: Tom Taylor <[email-masked]>
Date: Sun, 11 Oct 2009 10:32:47 -0400

I am resending this to the list as a matter of record -- Francois has already 
replied to it. The original fell into a black hole because I changed my E-mail 
address.

----

Please see below.

Francois Le Faucheur wrote:
>> In http://www.ietf.org/mail-archive/web/ancp/current/msg00955.html you 
>> said:
>> "Given that that Command TLVs will be present only in a limited set of 
>> message types, and "Cmnd Nmbr" is not one of the fields defined within 
>> the Command TLV, I would also remove "Cmnd Nmbr" from Status-Info. It 
>> can always be specified as part of the failureresponse to a particular 
>> message type."
>>
>> Response message because if it is needed we woudl use a more specific 
>> Response message?
[PTT]

>> For the case of a negative response to a Multicast Replication Control 
>> message: are you proposing that the Generic Response message be used 
>> (and then would it not have to contain the "Cmnd Nb") or are you 
>> saying that we would then use a new "Multicast Replication Control 
>> Response" which woudl contain the Cmnd Nb?
[PTT]
I would recommend a response specific to Multicast Replication Control. However,
my E-mail of 27/08/2009 suggested adding a new sub-TLV to Status-Info. To quote
from the earlier message:

*** command error

85    Command error

to base, and define in base a sub-TLV of Status-info to carry the sequence
number of the command within the message. This sub-TLV could also carry an
additional diagnostic code with its own IANA registry if people think it might
be useful. Extensions would define the actual code values and add them to the
registry. Likely candidates are some of the errors listed in section 4.4:

- Command not supported

- Malformed flow address

>>>>       in my opinion instead of submitting a new individual draft you 
>>>> should update the current mcast draft and propose your changes as a 
>>>> new version of the draft:
>>>> all my proposals, to serve as a basis for discussion that people can 
>>>> relate to.
>>>> What are your views?
>>>> Tom
>>>> alle persone indicate. La diffusione, copia o qualsiasi altra azione 
>>>> derivante dalla conoscenza di queste informazioni sono rigorosamente 
>>>> vietate. Qualora abbiate ricevuto questo documento per errore siete 
>>>> cortesemente pregati di darne immediata comunicazione al mittente e 
>>>> di provvedere alla sua distruzione, Grazie.
>>>> this message and any attachments and advise the sender by return 
>>>> e-mail, Thanks.
>>
> 
>

---

From: Tom Taylor <[email-masked]>
Date: Sun, 11 Oct 2009 10:33:44 -0400

Here is another message that got lost.

--------

I am looking for some principles here, so I've been dithering a bit myself over
the appropriate use of the Generic Response message. It seems fairly evident to
me that Generic Response should be used to convey error status that is common to
multiple message types, justifying the definition of the error cases in base
rather than another document. And I believe strongly that if there is
information that should be sent in a response in answer to a particular message
type, and that information is specific to that message type, then the response
message should be of the same type as the original request.

The questions in my mind begin when you have the latter case, but you have a
generic type of error to report. Do you report the error in a Generic Response,
or in the defined response message using a Status TLV embedded in that response
message? I think you do, to simplify the message-processing state machine. And
that means some changes in some of the work we have done already. Particularly,
my colleague Fortune Huang (18/08/2009) pointed out the complexity of handling
Delegated Bandwidth Query.

Francois Le Faucheur wrote:
>>>> within the Command TLV, I would also remove "Cmnd Nmbr" from 
>>>> Status-Info. It can always be specified as part of the 
>> I would recommend a response specific to Multicast Replication Control.
> 
> execute the complete Multicast Replication Control message successfully."
> 
> I can see that it would make sense to have a Generic Response message to 
> deal with a number of generic cases (such as when a message is not 
> recognized, or invalid).
> 
> Other than that, the MUlticast Status message was pretty much used as a 
> multi-purpose response already (only, limited to all multicast use cases).
> 
> Thanks
> 
> Francois
> 
>> sequence number of the command within the message. This sub-TLV could 
>> also carry an additional diagnostic code with its own IANA registry if 
>> people think it might be useful. Extensions would define the actual 
>> code values and add them to the registry. Likely candidates are some 
>> of the errors listed in section 4.4:
>>
>> - Command not supported
>>

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 12 Oct 2009 14:28:18 +0200

Hi Tom,

On 11 Oct 2009, at 16:33, Tom Taylor wrote:
> the appropriate use of the Generic Response message.

I see.

> It seems fairly evident to
> rather than another document.

The simple case is for "unrecognized/invalid message" where we need a  
generic message.

> And I believe strongly that if there is
> generic type of error to report.

Agreed.

> Do you report the error in a Generic Response,
> Delegated Bandwidth Query

That's probably a good case to look at.

There are some errors that are fairly specific to the Delegated  
Bandwidth Query (for example"Bandwidth Delegation not activated"). I  
understand you're saying you'd like to see those conveyed inside the  
"Delegated Bandwidth Query Response".

There are also some errors that are independent of the actual query  
type (for example "invalid Target"). I understand you're suggesting  
those also get conveyed via a type-specific response.

One even more interesting case is when we don't have a response  
defined already (eg for Multicast Replication Control message). Then  
should we create a new type-specific response (eg Multicast  
Replication Control response) or should we use the generic response  
(to avoid creating new message types)?

Francois

> .
>>>>> In http://www.ietf.org/mail-archive/web/ancp/current/ 
>>>>> msg00955.html you said:
>> * "I assume the text should really read that the receiver MUST send  
>> a Generic Response message with the appropriate contents if unable  
>> to execute the complete Multicast Replication Control message  
>> successfully."
>> Currently, the Multicast Status message can be used in many  
>> scenarios including in responses to:
>> Could you recap briefly what message you are proposing be used  
>> instead in each of these cases?
>> I can see that it would make sense to have a Generic Response  
>> message to deal with a number of generic cases (such as when a  
>> message is not recognized, or invalid).
>> Other than that, the MUlticast Status message was pretty much used  
>> as a multi-purpose response already (only, limited to all multicast  
>> use cases).
>> Thanks
>> Francois
>>> registry if people think it might be useful. Extensions would  
>>> define the actual code values and add them to the registry. Likely  
>>>>>>> all my proposals, to serve as a basis for discussion that  
>>>>>>> people can relate to.
>>>>>>> What are your views?
>>>>>>> Tom
>>>>>>> ricevuto questo documento per errore siete cortesemente  
>>>>>>> pregati di darne immediata comunicazione al mittente e di  
>>>>>>> provvedere alla sua distruzione, Grazie.
>>>>>>> This e-mail and any attachments is confidential and may  
>>>>>>> contain privileged information intended for the addressee(s)  
>>>>>>> only. Dissemination, copying, printing or use by anybody else  
>>>>>>> is unauthorised. If you are not the intended recipient, please  
>>>>>>> delete this message and any attachments and advise the sender  
>>>>>>> by return e-mail, Thanks.
>>>>>
>
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp