Subject: Re: [ANCP] Proposal for changing messages names in Multicast Control Extensions

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Tue, 14 Oct 2008 05:49:32 -0700

I'm ok with those renaming.

Do you mean that when the ANCP client ask authorization for a Join, its
request is a Multicast Replication Control Message and the reply from
the server is the same or different:____  While if the server is sending
a directive to the ANCP client to have a port join a multicast, do you
mean this is also called Multicast Replication Control Message?

>-----Original Message-----
>From: Maglione Roberta [mailto:[email-masked]] 
>Sent: Tuesday, October 14, 2008 7:46 AM
>To: Philippe Champagne (pchamp); 'DE CNODDER Stefaan'; 
>Wojciech Dec (wdec); 'Sanjay Wadhwa'
>Subject: Proposal for changing messages names in Multicast 
>Control Extensions 
>
>
>Hello,
>        I'm currently merging draft-ancp-mc-extensions with 
>draft-ietf-ancp-protocol, and I am thinking it could be useful 
>to simplify the terminology in terms of multicast message names.
>In particular I'd like to rename:
>- Multicast Replication Control Request Message in just 
>Multicast Replication Control Message
>- Multicast Status Response Message and in Multicast Status Message
>
>This change would allow re-using the same message type for 
>different purposes/use cases if needed in future, without 
>affecting current scenario.
>
>Please let me know what's your opinion on this proposal.
>
>Thanks and best regards,
>
>Roberta
>
>
>CONFIDENTIALITY NOTICE
>
>This message and its attachments are addressed solely to the 
>persons above and may contain confidential information. If you 
>have received the message in error, be informed that any use 
>of the content hereof is prohibited. Please return it 
>immediately to the sender and delete the message. Should you 
>have any questions, please contact us by replying to 
>[email-masked].
>
>        Thank you
>
>                                        www.telecomitalia.it
>
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 14 Oct 2008 15:21:54 +0200

Hi Phil,
        please see inline.

Regards,
Roberta

-----Original Message-----
From: Philippe Champagne (pchamp) [mailto:[email-masked]]
Sent: Tuesday, October 14, 2008 2:50 PM
To: Maglione Roberta; DE CNODDER Stefaan; Wojciech Dec (wdec); Sanjay Wadhwa
Cc: [email-masked]
Subject: RE: Proposal for changing messages names in Multicast Control Extensions

> I'm ok with those renaming.
[RM] Great

> the server is the same or different:____

[RM] not exactly, what I meant is slightly different:  when an ANCP client asks for authorization to Join a multicast flow, it uses an ANCP message (not defined yet), while when the server replies to the authorization message sent by the client it could use a Multicast Replication Control Message

> While if the server is sending

[RM] yes this is current scenario where the server uses a Multicast Replication Control Message to send a directive to the ANCP client to have a port join or leave a multicast flow.
Does it make sense?

Thanks,
Roberta

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

---

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Tue, 14 Oct 2008 06:32:54 -0700

Ok, just wanted to make sure what you meant.

So, this means a Multicast Replication Control Message would be used
both as a reply to an authorization as well as a directive.  I tend to
agree with this, although, we might review that case when we define the
authorization message and if the reply from the server would carry
roughly the same information as the directive. I would assume it would.

>Sent: Tuesday, October 14, 2008 9:22 AM
>To: Philippe Champagne (pchamp); DE CNODDER Stefaan; Wojciech 
>Dec (wdec); Sanjay Wadhwa
>Cc: [email-masked]
>> Do you mean that when the ANCP client ask authorization for a Join, 
>> its request is a Multicast Replication Control Message and the reply 
>> from the server is the same or different:____
>
>[RM] not exactly, what I meant is slightly different:  when an 
>ANCP client asks for authorization to Join a multicast flow, 
>it uses an ANCP message (not defined yet), while when the 
>server replies to the authorization message sent by the client 
>it could use a Multicast Replication Control Message
>
>[RM] yes this is current scenario where the server uses a 
>Multicast Replication Control Message to send a directive to 
>the ANCP client to have a port join or leave a multicast flow.
>Does it make sense?
>
>Thanks,
>Roberta
>
>
>
>
>>To: Philippe Champagne (pchamp); 'DE CNODDER Stefaan'; Wojciech Dec 
>>(wdec); 'Sanjay Wadhwa'
>>Subject: Proposal for changing messages names in Multicast Control 
>>Extensions
>>
>>
>>Hello,
>>draft-ietf-ancp-protocol, and I am thinking it could be useful to 
>>simplify the terminology in terms of multicast message names.
>>- Multicast Replication Control Request Message in just Multicast 
>>Replication Control Message
>>This change would allow re-using the same message type for different 
>>purposes/use cases if needed in future, without affecting current 
>>scenario.
>>
>>This message and its attachments are addressed solely to the persons 
>>above and may contain confidential information. If you have received 
>>the message in error, be informed that any use of the content 
>hereof is 
>>prohibited. Please return it immediately to the sender and delete the 
>>message. Should you have any questions, please contact us by replying 
>>to [email-masked].
>>
>>        Thank you
>>
>>                                        www.telecomitalia.it
>>
>
>
>CONFIDENTIALITY NOTICE
>

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Tue, 14 Oct 2008 15:50:40 +0200

Roberta,

I am fine with the renaming as well.

>affecting current scenario.

Are you talking about re-using both message types for something else in
the future, or are you only referring to the multicast status response
message?  Could you give an example of this future use?  

regards,
Stefaan

-----Original Message-----
From: Philippe Champagne (pchamp) [mailto:[email-masked]] 
Sent: dinsdag 14 oktober 2008 14:50
To: Maglione Roberta; DE CNODDER Stefaan; Wojciech Dec (wdec); Sanjay
Wadhwa
Cc: [email-masked]
Subject: RE: Proposal for changing messages names in Multicast Control
Extensions

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 14 Oct 2008 15:59:50 +0200

Hi Stefaan,
        please see inline.
Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, October 14, 2008 3:51 PM
To: Maglione Roberta
Cc: [email-masked]
Subject: RE: Proposal for changing messages names in Multicast Control Extensions

Roberta,

[RM] great

[RM] I was thinking more about reusing Multicast Replication Control Message in the following scenario:
when an ANCP client asks for authorization to Join a multicast flow, it uses an ANCP message (not defined yet), while when the server replies to the authorization message sent by the client it could use a Multicast Replication Control Message

-----Original Message-----
From: Philippe Champagne (pchamp) [mailto:[email-masked]]
Sent: dinsdag 14 oktober 2008 14:50
To: Maglione Roberta; DE CNODDER Stefaan; Wojciech Dec (wdec); Sanjay
Wadhwa
Cc: [email-masked]

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 14 Oct 2008 16:01:35 +0200

Roberta and all,
I support these name changes.

Stefaan,
One example is (re)using the Multicast Replication Control message as  
a "response" to a multicast admission request from AN (eg when AN  
receives an IGMP Join).

Francois

On 14 Oct 2008, at 15:50, DE CNODDER Stefaan wrote:

> its

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Wed, 15 Oct 2008 14:09:30 +0200

If a message can be used as both a request and a reply, is the defitions
of the Transaction Identifier still accurate?  Currently the draft says:

- trans id in request is linearly incrementing, and is per message type
- trans id in response is copied from request

If the same message type can be both request and response, then how will
the trans id behave?  Should the receiver first try to find out whether
it is a request or a response, and then process it accordingly?  Or how
should it then work?

regards,
Stefaan

-----Original Message-----
From: Philippe Champagne (pchamp) [mailto:[email-masked]] 
Sent: dinsdag 14 oktober 2008 15:33
To: Maglione Roberta; DE CNODDER Stefaan; Wojciech Dec (wdec); Sanjay
Wadhwa
Cc: [email-masked]

>To: Philippe Champagne (pchamp); DE CNODDER Stefaan; Wojciech Dec 
>(wdec); Sanjay Wadhwa
>Cc: [email-masked]
>[RM] not exactly, what I meant is slightly different:  when an ANCP 
>client asks for authorization to Join a multicast flow, it uses an ANCP

>message (not defined yet), while when the server replies to the 
>authorization message sent by the client it could use a Multicast 
>[RM] yes this is current scenario where the server uses a Multicast 
>Replication Control Message to send a directive to the ANCP client to 
>have a port join or leave a multicast flow.
>Does it make sense?
>
>Thanks,
>Roberta
>
>
>
>
>the message in error, be informed that any use of the content hereof is

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 15 Oct 2008 15:19:14 +0200

> it is a request or a response, and then process it accordingly?  Or  

One option would be for the sender to look at the Result field:
	* if it is set to Success/Failure, then this message is a "response"  
to an earlier request (and its Transaction ID echoed the one of the  
request)
	* if it is set to Ack/Nack, then this messages is a request (and the  
transaction ID was generated by remote end)

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 15 Oct 2008 15:23:07 +0200

>> it is a request or a response, and then process it accordingly?  Or  

Oops, there was a typo in earlier message. This should read:
One option would be for the receiver to look at the Result field:
	* if it is set to Success/Failure, then this message is a "response"  
to an earlier request (and its Transaction ID echoed the one of the  
request)
	* if it is set to Ack/Nack, then this messages is a "request" (and  
the transaction ID was generated by remote end)

> 	* if it is set to Success/Failure, then this message is a  
> "response" to an earlier request (and its Transaction ID echoed the  
> one of the request)
> 	* if it is set to Ack/Nack, then this messages is a request (and  
> the transaction ID was generated by remote end)
>
>>
>>
>> regards,
>> Stefaan
>>
>>
>>>> different
>>>> persons

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 15 Oct 2008 16:26:34 +0200

> the transaction ID was generated by remote end)

Note also that the AN may not even care that much whether it is a  
response or a spontaneous request, because the two are idempotent.

Francois

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Wed, 15 Oct 2008 16:36:29 +0200

Francois,
 
If it is a request, then the AN just executes the commands.  If it is a
response, then I would think it has to look up the state indexed by
trans id to clean it up, and to execute the join which is in that state.
So yes, it looks to me that both are different.  Also the processing of
the trans id is different because for requests it has to check whether
it is each time incremented by 1, which it does not have to do for
responses.
 
regards,
Stefaan

________________________________

From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: woensdag 15 oktober 2008 16:27
To: Francois Le Faucheur IMAP
Cc: DE CNODDER Stefaan; [email-masked]
Subject: Re: [ANCP] Proposal for changing messages names in Multicast
Control Extensions

			If a message can be used as both a request and a
reply, is the defitions

			of the Transaction Identifier still accurate?
Currently the draft says:

			- trans id in request is linearly incrementing,
and is per message type

			If the same message type can be both request and
response, then how will

			the trans id behave?  Should the receiver first
try to find out whether

			it is a request or a response, and then process
it accordingly?  Or how

			should it then work?

	Oops, there was a typo in earlier message. This should read:
	One option would be for the receiver to look at the Result
field:
	* if it is set to Success/Failure, then this message is a
"response" to an earlier request (and its Transaction ID echoed the one
of the request)
	* if it is set to Ack/Nack, then this messages is a "request"
(and the transaction ID was generated by remote end)

Francois

		One option would be for the sender to look at the Result
field:

		* if it is set to Success/Failure, then this message is
a "response" to an earlier request (and its Transaction ID echoed the
one of the request)

		* if it is set to Ack/Nack, then this messages is a
request (and the transaction ID was generated by remote end)

			regards,

			Stefaan

			-----Original Message-----

			From: Philippe Champagne (pchamp)
[mailto:[email-masked]]

			To: Maglione Roberta; DE CNODDER Stefaan;
Wojciech Dec (wdec); Sanjay

			Wadhwa

			Cc: [email-masked]

			Subject: RE: Proposal for changing messages
names in Multicast Control

			Extensions

			So, this means a Multicast Replication Control
Message would be used

			both as a reply to an authorization as well as a
directive.  I tend to

			agree with this, although, we might review that
case when we define the

			authorization message and if the reply from the
server would carry

			roughly the same information as the directive. I
would assume it would.

				-----Original Message-----

				From: Maglione Roberta
[mailto:[email-masked]]

				To: Philippe Champagne (pchamp); DE
CNODDER Stefaan; Wojciech Dec

				(wdec); Sanjay Wadhwa

				Cc: [email-masked]

				Subject: RE: Proposal for changing
messages names in Multicast Control

				Extensions

				Hi Phil,

				    please see inline.

				Regards,

				Roberta

				-----Original Message-----

				From: Philippe Champagne (pchamp)
[mailto:[email-masked]]

				To: Maglione Roberta; DE CNODDER
Stefaan; Wojciech Dec (wdec); Sanjay

				Wadhwa

				Cc: [email-masked]

				Subject: RE: Proposal for changing
messages names in Multicast Control

				Extensions

				[RM] Great

				Do you mean that when the ANCP client
ask authorization for a Join,

				its request is a Multicast Replication
Control Message and the reply

				from the server is the same or
different:____

				[RM] not exactly, what I meant is
slightly different:  when an ANCP

				client asks for authorization to Join a
multicast flow, it uses an ANCP

				message (not defined yet), while when
the server replies to the

				authorization message sent by the client
it could use a Multicast

				a directive to the ANCP client to have a
port join a

				multicast, do you

				mean this is also called Multicast
Replication Control Message?

				[RM] yes this is current scenario where
the server uses a Multicast

				Replication Control Message to send a
directive to the ANCP client to

				have a port join or leave a multicast
flow.

				Does it make sense?

				Thanks,

				Roberta

				-----Original Message-----

				From: Maglione Roberta
[mailto:[email-masked]]

				To: Philippe Champagne (pchamp); 'DE
CNODDER Stefaan'; Wojciech Dec

				(wdec); 'Sanjay Wadhwa'

				Subject: Proposal for changing messages
names in Multicast Control

				Extensions

				Hello,

				    I'm currently merging
draft-ancp-mc-extensions with

				draft-ietf-ancp-protocol, and I am
thinking it could be useful to

				simplify the terminology in terms of
multicast message names.

				- Multicast Replication Control Request
Message in just Multicast

				- Multicast Status Response Message and
in Multicast Status Message

				This change would allow re-using the
same message type for different

				purposes/use cases if needed in future,
without affecting current

				scenario.

				Please let me know what's your opinion
on this proposal.

				Thanks and best regards,

				Roberta

				CONFIDENTIALITY NOTICE

				This message and its attachments are
addressed solely to the persons

				above and may contain confidential
information. If you have received

				the message in error, be informed that
any use of the content

				hereof is

				prohibited. Please return it immediately
to the sender and delete the

				message. Should you have any questions,
please contact us by replying

				    Thank you

www.telecomitalia.it

				CONFIDENTIALITY NOTICE

				This message and its attachments are
addressed solely to the persons

				above and may contain confidential
information. If you have received

				the message in error, be informed that
any use of the content hereof is

				prohibited. Please return it immediately
to the sender and delete the

				message. Should you have any questions,
please contact us by replying

				    Thank you

www.telecomitalia.it

			ANCP mailing list

			[email-masked]

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 15 Oct 2008 17:52:44 +0200

Hi Stefaan,

On 15 Oct 2008, at 16:36, DE CNODDER Stefaan wrote:

>
> Francois,
>
> If it is a request, then the AN just executes the commands.  If it  
> is a response, then I would think it has to look up the state  
> indexed by trans id to clean it up, and to execute the join which is  
> in that state.

First, just to make sure we don't lose the first point: if the AN  
needs to know whether it is a request or a response, it could do so  
via the Result code.

Now regarding whether AN needs to know, that may be implementation  
dependent.
One model could be as you described above, in which case AN needs to  
know.
Another model could be where the AN operates in a simpler "Fire and  
Forget" mode:
	* AN sends admission request (and AN increments its Transaction ID  
value)
	* AN forgets about it (AN relies on TCP to make sure request reached  
NAS and relies on ANCP behavior to get a response)
	* when AN gets a Multicast Replication message, it just executes. A  
key assumption here is that the multicast replication control message  
contains all the information necessary for execution (eg "add channel  
C to port P")

Makes sense?

Francois

>   So yes, it looks to me that both are different.  Also the  
> processing of the trans id is different because for requests it has  
> to check whether it is each time incremented by 1, which it does not  
> have to do for responses.
>
> regards,
> Stefaan
>
> Subject: Re: [ANCP] Proposal for changing messages names in  
> Multicast Control Extensions
>
>>>>
>>>>
>>> "response" to an earlier request (and its Transaction ID echoed  
>>> the one of the request)
>>>>> ANCP
>>>>> Multicast
>>>>>> Control

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Wed, 15 Oct 2008 18:08:16 +0200

About the "fire and forget".  I like it a lot because of its simplicity
but it has an issue:
 
1) user sends join matching grey list
2) AN sends admission request to NAS and forgets about it
3) user sends leave, which is not doing anything since the NAS has not
replied yet
4) AN receives possitive answer to join the stream
 
In this case the multicast flow is replicated to the line although the
user had sent a leave.
 
First processing the Result field without knowing what the message is
about looks to me like a strange way of processing, but it works.
However, just using a different message type would make it easier
according to me.  No need to repeat all commands or even no need to
repeat the port id, so not much re-use anyhow.
 
If the "fire and forget" method would work, there is not really a
response, and the current message as defined today is sufficient, but in
the above case I have some doubts.
 
regards,
Stefaan

From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: woensdag 15 oktober 2008 17:53
To: DE CNODDER Stefaan
Cc: Francois Le Faucheur IMAP; [email-masked]; Philippe (pchamp)
Champagne
Subject: Re: [ANCP] Proposal for changing messages names in Multicast
Control Extensions

Hi Stefaan, 

	 
	Francois,
	 
	If it is a request, then the AN just executes the commands.  If
it is a response, then I would think it has to look up the state indexed
by trans id to clean it up, and to execute the join which is in that
state.

First, just to make sure we don't lose the first point: if the AN needs
to know whether it is a request or a response, it could do so via the
Result code.

Now regarding whether AN needs to know, that may be implementation
dependent.
One model could be as you described above, in which case AN needs to
know.
Another model could be where the AN operates in a simpler "Fire and
Forget" mode:
* AN sends admission request (and AN increments its Transaction ID
value)
* AN forgets about it (AN relies on TCP to make sure request reached NAS
and relies on ANCP behavior to get a response)
* when AN gets a Multicast Replication message, it just executes. A key
assumption here is that the multicast replication control message
contains all the information necessary for execution (eg "add channel C
to port P")

Makes sense?

Francois

	  So yes, it looks to me that both are different.  Also the
processing of the trans id is different because for requests it has to
check whether it is each time incremented by 1, which it does not have
to do for responses.
	 
	regards,
	Stefaan

				

				If a message can be used as both a
request and a reply, is the defitions

				of the Transaction Identifier still
accurate?  Currently the draft says:

				- trans id in request is linearly
incrementing, and is per message type

				- trans id in response is copied from
request

				If the same message type can be both
request and response, then how will

				the trans id behave?  Should the
receiver first try to find out whether

				it is a request or a response, and then
process it accordingly?  Or how

				should it then work?

		Oops, there was a typo in earlier message. This should
read:
		One option would be for the receiver to look at the
Result field:
		* if it is set to Success/Failure, then this message is
a "response" to an earlier request (and its Transaction ID echoed the
one of the request)
		* if it is set to Ack/Nack, then this messages is a
"request" (and the transaction ID was generated by remote end)

	Note also that the AN may not even care that much whether it is
a response or a spontaneous request, because the two are idempotent.

	Francois

			One option would be for the sender to look at
the Result field:

			* if it is set to Success/Failure, then this
message is a "response" to an earlier request (and its Transaction ID
echoed the one of the request)

			* if it is set to Ack/Nack, then this messages
is a request (and the transaction ID was generated by remote end)

				regards,

				Stefaan

				-----Original Message-----

				Wadhwa

				Cc: [email-masked]

				Extensions

				Ok, just wanted to make sure what you
meant.

				So, this means a Multicast Replication
Control Message would be used

				both as a reply to an authorization as
well as a directive.  I tend to

				agree with this, although, we might
review that case when we define the

				authorization message and if the reply
from the server would carry

				roughly the same information as the
directive. I would assume it would.

				-----Original Message-----

				From: Maglione Roberta

				(wdec); Sanjay Wadhwa

				Cc: [email-masked]

				Extensions

				Hi Phil,

				    please see inline.

				Regards,

				Roberta

				-----Original Message-----

				Wadhwa

				Cc: [email-masked]

				Extensions

				[RM] Great

				multicast, do you

				Does it make sense?

				Thanks,

				Roberta

				-----Original Message-----

				From: Maglione Roberta

				(wdec); 'Sanjay Wadhwa'

				Extensions

				Hello,

				    I'm currently merging

				scenario.

				Thanks and best regards,

				Roberta

				CONFIDENTIALITY NOTICE

				hereof is

				    Thank you

www.telecomitalia.it

				CONFIDENTIALITY NOTICE

				    Thank you

www.telecomitalia.it

				ANCP mailing list

				[email-masked]

---

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Wed, 15 Oct 2008 11:08:09 -0700

Hi Stefaan
 
I think it could go this way:
 
Either the AN also sends the Leave to the NAS - which will be processed
serially by the NAS after the Join, and the NAS therefore will reply for
the leave shortly after. In this case, the AN gets a leave.
or
The AN does not sends the Leave to the NAS but holds it for a specific
time (the time we should expect such join from the server). 
 
For the fire and forget, I personally prefer the first option, I mean,
if we have to have the AN holding info, might as well be the whole thing
where it knows also about the JOIN sent shortly before for which it is
awaiting a response.
 
The question is then, which way to go?  Can we allow "fire and forget"
and "remember the states" to both be used at the discretion of the
implementor of the ANCP client or do we force one way to go.  
It depends if the ANCP server needs to know about bandwidth usage for
bandwidth requirement decision, in which case, it would need to know
about Leave as well, isn't it?   Can that behavior (bandwith decision)
be configurable, allowing "remember the states" (where Leaves are not
necessarily forwarded) to exist in other deployment model?

	From: DE CNODDER Stefaan
[mailto:[email-masked]] 
	Sent: Wednesday, October 15, 2008 12:08 PM
	To: Francois Le Faucheur (flefauch)
	Cc: [email-masked]; Philippe Champagne (pchamp)
	Subject: RE: [ANCP] Proposal for changing messages names in
Multicast Control Extensions

	About the "fire and forget".  I like it a lot because of its
simplicity but it has an issue:
	 
	1) user sends join matching grey list
	2) AN sends admission request to NAS and forgets about it
	3) user sends leave, which is not doing anything since the NAS
has not replied yet
	4) AN receives possitive answer to join the stream
	 
	In this case the multicast flow is replicated to the line
although the user had sent a leave.
	 
	First processing the Result field without knowing what the
message is about looks to me like a strange way of processing, but it
works.  However, just using a different message type would make it
easier according to me.  No need to repeat all commands or even no need
to repeat the port id, so not much re-use anyhow.
	 
	If the "fire and forget" method would work, there is not really
a response, and the current message as defined today is sufficient, but
in the above case I have some doubts.
	 
	regards,
	Stefaan

	Hi Stefaan, 

		 
		Francois,
		 
		If it is a request, then the AN just executes the
commands.  If it is a response, then I would think it has to look up the
state indexed by trans id to clean it up, and to execute the join which
is in that state.

	First, just to make sure we don't lose the first point: if the
AN needs to know whether it is a request or a response, it could do so
via the Result code.

	Now regarding whether AN needs to know, that may be
implementation dependent.
	One model could be as you described above, in which case AN
needs to know.
	Another model could be where the AN operates in a simpler "Fire
and Forget" mode:
	* AN sends admission request (and AN increments its Transaction
ID value)
	* AN forgets about it (AN relies on TCP to make sure request
reached NAS and relies on ANCP behavior to get a response)
	* when AN gets a Multicast Replication message, it just
executes. A key assumption here is that the multicast replication
control message contains all the information necessary for execution (eg
"add channel C to port P")

	Makes sense?

	Francois

		  So yes, it looks to me that both are different.  Also
the processing of the trans id is different because for requests it has
to check whether it is each time incremented by 1, which it does not
have to do for responses.
		 
		regards,
		Stefaan

		From: Francois Le Faucheur IMAP
[mailto:[email-masked]] 
		Sent: woensdag 15 oktober 2008 16:27
		To: Francois Le Faucheur IMAP
		Cc: DE CNODDER Stefaan; [email-masked]
		Subject: Re: [ANCP] Proposal for changing messages names
in Multicast Control Extensions

				should it then work?

			Oops, there was a typo in earlier message. This
should read:
			One option would be for the receiver to look at
the Result field:
			* if it is set to Success/Failure, then this
message is a "response" to an earlier request (and its Transaction ID
echoed the one of the request)
			* if it is set to Ack/Nack, then this messages
is a "request" (and the transaction ID was generated by remote end)

		Note also that the AN may not even care that much
whether it is a response or a spontaneous request, because the two are
idempotent.

		Francois

				One option would be for the sender to
look at the Result field:

				* if it is set to Success/Failure, then
this message is a "response" to an earlier request (and its Transaction
ID echoed the one of the request)

				* if it is set to Ack/Nack, then this
messages is a request (and the transaction ID was generated by remote
end)

				regards,

				Stefaan

				-----Original Message-----

				Wadhwa

				Cc: [email-masked]

				Extensions

				-----Original Message-----

				From: Maglione Roberta

				(wdec); Sanjay Wadhwa

				Cc: [email-masked]

				Extensions

				Hi Phil,

				    please see inline.

				Regards,

				Roberta

				-----Original Message-----

				Wadhwa

				Cc: [email-masked]

				Extensions

				[RM] Great

				multicast, do you

				Does it make sense?

				Thanks,

				Roberta

				-----Original Message-----

				From: Maglione Roberta

				(wdec); 'Sanjay Wadhwa'

				Extensions

				Hello,

				    I'm currently merging

				scenario.

				Thanks and best regards,

				Roberta

				CONFIDENTIALITY NOTICE

				hereof is

				    Thank you

www.telecomitalia.it

				CONFIDENTIALITY NOTICE

				    Thank you

www.telecomitalia.it

				ANCP mailing list

				[email-masked]

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 16 Oct 2008 08:37:45 +0200

On 15 Oct 2008, at 18:08, DE CNODDER Stefaan wrote:

> 3) user sends leave,

Then the AN would "Fire and Forget" an ANCP message conveying the  
Leave (whether or not the NAS has already responded to the previous  
admission request).
So I'm not sure the above scenario creates an issue.

The AN is effectively responsible for conveying all the Join/leave  
transitions to the NAS and relies on NAS to process and then instruct  
back the AN to perform the resulting replication add/delete for  
<channels,ports>.

Francois

> which is not doing anything since the NAS has not replied yet
> In this case the multicast flow is replicated to the line although  
> the user had sent a leave.
>
> First processing the Result field without knowing what the message  
> is about looks to me like a strange way of processing, but it  
> easier according to me.  No need to repeat all commands or even no  
> need to repeat the port id, so not much re-use anyhow.
>
> response, and the current message as defined today is sufficient,  
> but in the above case I have some doubts.
>
> regards,
> Stefaan
>
>> indexed by trans id to clean it up, and to execute the join which  
>> is in that state.
>
> key assumption here is that the multicast replication control  
> message contains all the information necessary for execution (eg  
>> to check whether it is each time incremented by 1, which it does  
>> not have to do for responses.
>>
>> regards,
>> Stefaan
>>
>>>>>>> to

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 16 Oct 2008 09:11:19 +0200

Philippe, Stefaan,

On 15 Oct 2008, at 20:08, Philippe Champagne (pchamp) wrote:

> Either the AN also sends the Leave to the NAS - which will be  
> processed serially by the NAS after the Join, and the NAS therefore  
> will reply for the leave shortly after. In this case, the AN gets a  
> leave.
> or
> The AN does not sends the Leave to the NAS but holds it for a  
> specific time (the time we should expect such join from the server).
>
> For the fire and forget, I personally prefer the first option, I  
> mean, if we have to have the AN holding info, might as well be the  
> whole thing where it knows also about the JOIN sent shortly before  
> for which it is awaiting a response.
>
> The question is then, which way to go?  Can we allow "fire and  
> forget" and "remember the states" to both be used at the discretion  
> of the implementor of the ANCP client or do we force one way to go.
> It depends if the ANCP server needs to know about bandwidth usage  
> for bandwidth requirement decision, in which case, it would need to  
> know about Leave as well, isn't it?   Can that behavior (bandwith  
> decision) be configurable, allowing "remember the states" (where  
> Leaves are not necessarily forwarded) to exist in other deployment  
> model?

I would say that we already have a model to allow the AN to operate  
fairly autonomously (ie Black List & White-List + Bandwidth  
delegation). In that model, the NAS does not need to track all join/ 
leaves and we take advantage of that to have AN handles Join/Leave  
without having to keep NAS aware of all that..

The Admission Control request that we are discussing in the thread is  
associated with the Grey-List Model where the NAS is likely to need to  
track all join/leaves (eg because admission control is performed by  
NAS or Policy Server, perhaps for accounting reason, perhaps for  
conditional access). So to mimimze the number of options, I would  
suggest that in this case of Grey-List operation, we only allow a  
single behavior whereby the AN conveys all the Leave/Join transitions  
to NAS.
Note that the AN may use some liberty in how it does that (eg. it may  
optionally wait a little bit on receipt of a Leave to see if a Join is  
not immediately following to bundle that in a single ANCP request, it  
may decide to remember the state for a while or until it gets a  
response,...) but I would suggest that no matter what the AN should  
always convey all Join/Leave transitions (in this Grey-List Model).

Makes sense?

Francois

> 3) user sends leave, which is not doing anything since the NAS has  
> not replied yet

---

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Thu, 16 Oct 2008 04:45:11 -0700

Yes, that's true, I forgot to mention the greylist as the white list
makes the AN able to operate autonomously.
And yes, I think it make more sense for the AN to sends the leaves as
well.

	From: Francois Le Faucheur (flefauch) 
	Sent: Thursday, October 16, 2008 3:11 AM
	To: Philippe Champagne (pchamp)
	Cc: Francois Le Faucheur (flefauch); DE CNODDER Stefaan;
[email-masked]
	Subject: Re: [ANCP] Proposal for changing messages names in
Multicast Control Extensions

	Philippe, Stefaan, 

		Hi Stefaan

		Either the AN also sends the Leave to the NAS - which
will be processed serially by the NAS after the Join, and the NAS
therefore will reply for the leave shortly after. In this case, the AN
gets a leave.
		or
		The AN does not sends the Leave to the NAS but holds it
for a specific time (the time we should expect such join from the
server). 
		 
		For the fire and forget, I personally prefer the first
option, I mean, if we have to have the AN holding info, might as well be
the whole thing where it knows also about the JOIN sent shortly before
for which it is awaiting a response.
		 
		The question is then, which way to go?  Can we allow
"fire and forget" and "remember the states" to both be used at the
discretion of the implementor of the ANCP client or do we force one way
to go.  
		It depends if the ANCP server needs to know about
bandwidth usage for bandwidth requirement decision, in which case, it
would need to know about Leave as well, isn't it?   Can that behavior
(bandwith decision) be configurable, allowing "remember the states"
(where Leaves are not necessarily forwarded) to exist in other
deployment model?

	I would say that we already have a model to allow the AN to
operate fairly autonomously (ie Black List & White-List + Bandwidth
delegation). In that model, the NAS does not need to track all
join/leaves and we take advantage of that to have AN handles Join/Leave
without having to keep NAS aware of all that..

	The Admission Control request that we are discussing in the
thread is associated with the Grey-List Model where the NAS is likely to
need to track all join/leaves (eg because admission control is performed
by NAS or Policy Server, perhaps for accounting reason, perhaps for
conditional access). So to mimimze the number of options, I would
suggest that in this case of Grey-List operation, we only allow a single
behavior whereby the AN conveys all the Leave/Join transitions to NAS.
	Note that the AN may use some liberty in how it does that (eg.
it may optionally wait a little bit on receipt of a Leave to see if a
Join is not immediately following to bundle that in a single ANCP
request, it may decide to remember the state for a while or until it
gets a response,...) but I would suggest that no matter what the AN
should always convey all Join/Leave transitions (in this Grey-List
Model).

	Makes sense?

	Francois

			From: DE CNODDER Stefaan
[mailto:[email-masked]] 
			Sent: Wednesday, October 15, 2008 12:08 PM
			To: Francois Le Faucheur (flefauch)
			Cc: [email-masked]; Philippe Champagne (pchamp)
			Subject: RE: [ANCP] Proposal for changing
messages names in Multicast Control Extensions

			About the "fire and forget".  I like it a lot
because of its simplicity but it has an issue:
			 
			1) user sends join matching grey list
			2) AN sends admission request to NAS and forgets
about it
			3) user sends leave, which is not doing anything
since the NAS has not replied yet
			4) AN receives possitive answer to join the
stream
			 
			In this case the multicast flow is replicated to
the line although the user had sent a leave.
			 
			First processing the Result field without
knowing what the message is about looks to me like a strange way of
processing, but it works.  However, just using a different message type
would make it easier according to me.  No need to repeat all commands or
even no need to repeat the port id, so not much re-use anyhow.
			 
			If the "fire and forget" method would work,
there is not really a response, and the current message as defined today
is sufficient, but in the above case I have some doubts.
			 
			regards,
			Stefaan

			From: Francois Le Faucheur IMAP
[mailto:[email-masked]] 
			Sent: woensdag 15 oktober 2008 17:53
			To: DE CNODDER Stefaan
			Cc: Francois Le Faucheur IMAP; [email-masked];
Philippe (pchamp) Champagne
			Subject: Re: [ANCP] Proposal for changing
messages names in Multicast Control Extensions

			Hi Stefaan, 

			On 15 Oct 2008, at 16:36, DE CNODDER Stefaan
wrote:

				Francois,
				 
				If it is a request, then the AN just
executes the commands.  If it is a response, then I would think it has
to look up the state indexed by trans id to clean it up, and to execute
the join which is in that state.

			First, just to make sure we don't lose the first
point: if the AN needs to know whether it is a request or a response, it
could do so via the Result code.

			Now regarding whether AN needs to know, that may
be implementation dependent.
			One model could be as you described above, in
which case AN needs to know.
			Another model could be where the AN operates in
a simpler "Fire and Forget" mode:
			* AN sends admission request (and AN increments
its Transaction ID value)
			* AN forgets about it (AN relies on TCP to make
sure request reached NAS and relies on ANCP behavior to get a response)
			* when AN gets a Multicast Replication message,
it just executes. A key assumption here is that the multicast
replication control message contains all the information necessary for
execution (eg "add channel C to port P")

			Makes sense?

			Francois

				  So yes, it looks to me that both are
different.  Also the processing of the trans id is different because for
requests it has to check whether it is each time incremented by 1, which
it does not have to do for responses.
				 
				regards,
				Stefaan

				From: Francois Le Faucheur IMAP
[mailto:[email-masked]] 
				Sent: woensdag 15 oktober 2008 16:27
				To: Francois Le Faucheur IMAP
				Cc: DE CNODDER Stefaan; [email-masked]
				Subject: Re: [ANCP] Proposal for
changing messages names in Multicast Control Extensions

				should it then work?

				Oops, there was a typo in earlier
message. This should read:
				One option would be for the receiver to
look at the Result field:
				* if it is set to Success/Failure, then
this message is a "response" to an earlier request (and its Transaction
ID echoed the one of the request)
				* if it is set to Ack/Nack, then this
messages is a "request" (and the transaction ID was generated by remote
end)

				Note also that the AN may not even care
that much whether it is a response or a spontaneous request, because the
two are idempotent.

				Francois

				regards,

				Stefaan

				-----Original Message-----

				Wadhwa

				Cc: [email-masked]

				Extensions

				-----Original Message-----

				From: Maglione Roberta

				(wdec); Sanjay Wadhwa

				Cc: [email-masked]

				Extensions

				Hi Phil,

				    please see inline.

				Regards,

				Roberta

				-----Original Message-----

				Wadhwa

				Cc: [email-masked]

				Extensions

				[RM] Great

				multicast, do you

				Does it make sense?

				Thanks,

				Roberta

				-----Original Message-----

				From: Maglione Roberta

				(wdec); 'Sanjay Wadhwa'

				Extensions

				Hello,

				    I'm currently merging

				scenario.

				Thanks and best regards,

				Roberta

				CONFIDENTIALITY NOTICE

				hereof is

				    Thank you

www.telecomitalia.it

				CONFIDENTIALITY NOTICE

				    Thank you

www.telecomitalia.it

				ANCP mailing list

				[email-masked]

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Fri, 17 Oct 2008 11:02:42 +0200

Makes sense to me as well.  

From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: donderdag 16 oktober 2008 9:11
To: Philippe Champagne (pchamp)
Cc: Francois Le Faucheur IMAP; DE CNODDER Stefaan; [email-masked]
Subject: Re: [ANCP] Proposal for changing messages names in Multicast
Control Extensions

Philippe, Stefaan, 

	Hi Stefaan

	Either the AN also sends the Leave to the NAS - which will be
processed serially by the NAS after the Join, and the NAS therefore will
reply for the leave shortly after. In this case, the AN gets a leave.
	or
	The AN does not sends the Leave to the NAS but holds it for a
specific time (the time we should expect such join from the server). 
	 
	For the fire and forget, I personally prefer the first option, I
mean, if we have to have the AN holding info, might as well be the whole
thing where it knows also about the JOIN sent shortly before for which
it is awaiting a response.
	 
	The question is then, which way to go?  Can we allow "fire and
forget" and "remember the states" to both be used at the discretion of
the implementor of the ANCP client or do we force one way to go.  
	It depends if the ANCP server needs to know about bandwidth
usage for bandwidth requirement decision, in which case, it would need
to know about Leave as well, isn't it?   Can that behavior (bandwith
decision) be configurable, allowing "remember the states" (where Leaves
are not necessarily forwarded) to exist in other deployment model?

I would say that we already have a model to allow the AN to operate
fairly autonomously (ie Black List & White-List + Bandwidth delegation).
In that model, the NAS does not need to track all join/leaves and we
take advantage of that to have AN handles Join/Leave without having to
keep NAS aware of all that..

The Admission Control request that we are discussing in the thread is
associated with the Grey-List Model where the NAS is likely to need to
track all join/leaves (eg because admission control is performed by NAS
or Policy Server, perhaps for accounting reason, perhaps for conditional
access). So to mimimze the number of options, I would suggest that in
this case of Grey-List operation, we only allow a single behavior
whereby the AN conveys all the Leave/Join transitions to NAS.
Note that the AN may use some liberty in how it does that (eg. it may
optionally wait a little bit on receipt of a Leave to see if a Join is
not immediately following to bundle that in a single ANCP request, it
may decide to remember the state for a while or until it gets a
response,...) but I would suggest that no matter what the AN should
always convey all Join/Leave transitions (in this Grey-List Model).

Makes sense?

Francois

		From: DE CNODDER Stefaan
		Subject: RE: [ANCP] Proposal for changing messages names

		About the "fire and forget".  I like it a lot because of
its simplicity but it has an issue:
		 
		1) user sends join matching grey list
		2) AN sends admission request to NAS and forgets about
it
		3) user sends leave, which is not doing anything since
the NAS has not replied yet
		4) AN receives possitive answer to join the stream
		 
		In this case the multicast flow is replicated to the
line although the user had sent a leave.
		 
		First processing the Result field without knowing what
the message is about looks to me like a strange way of processing, but
it works.  However, just using a different message type would make it
easier according to me.  No need to repeat all commands or even no need
to repeat the port id, so not much re-use anyhow.
		 
		If the "fire and forget" method would work, there is not
really a response, and the current message as defined today is
sufficient, but in the above case I have some doubts.
		 
		regards,
		Stefaan

		Cc: Francois Le Faucheur IMAP; [email-masked]; Philippe
(pchamp) Champagne

		Hi Stefaan, 

			 
			Francois,
			 
			If it is a request, then the AN just executes
the commands.  If it is a response, then I would think it has to look up
the state indexed by trans id to clean it up, and to execute the join
which is in that state.

		First, just to make sure we don't lose the first point:
if the AN needs to know whether it is a request or a response, it could
do so via the Result code.

		Now regarding whether AN needs to know, that may be
implementation dependent.
		One model could be as you described above, in which case
AN needs to know.
		Another model could be where the AN operates in a
simpler "Fire and Forget" mode:
		* AN sends admission request (and AN increments its
Transaction ID value)
		* AN forgets about it (AN relies on TCP to make sure
request reached NAS and relies on ANCP behavior to get a response)
		* when AN gets a Multicast Replication message, it just
executes. A key assumption here is that the multicast replication
control message contains all the information necessary for execution (eg
"add channel C to port P")

		Makes sense?

		Francois

			regards,
			Stefaan

				

				should it then work?

			Note also that the AN may not even care that
much whether it is a response or a spontaneous request, because the two
are idempotent.

			Francois

				regards,

				Stefaan

				-----Original Message-----

				Wadhwa

				Cc: [email-masked]

				Extensions

				-----Original Message-----

				From: Maglione Roberta

				(wdec); Sanjay Wadhwa

				Cc: [email-masked]

				Extensions

				Hi Phil,

				    please see inline.

				Regards,

				Roberta

				-----Original Message-----

				Wadhwa

				Cc: [email-masked]

				Extensions

				[RM] Great

				multicast, do you

				Does it make sense?

				Thanks,

				Roberta

				-----Original Message-----

				From: Maglione Roberta

				(wdec); 'Sanjay Wadhwa'

				Extensions

				Hello,

				    I'm currently merging

				scenario.

				Thanks and best regards,

				Roberta

				CONFIDENTIALITY NOTICE

				hereof is

				    Thank you

www.telecomitalia.it

				CONFIDENTIALITY NOTICE

				    Thank you

www.telecomitalia.it

				ANCP mailing list

				[email-masked]