Subject: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up)

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 22 Nov 2007 14:54:58 +0100

Hello,

On 19 Sep 2007, at 15:56, Francois Le Faucheur IMAP wrote:

> Sanjay and all,
<clip>

> 	2) you raise a valid point that there are ANCP deployment  
> variations whereby the replication on AN may be controlled by NAS  
> via ANCP, but where the "join/leave" information may not be  
> conveyed to NAS via ANCP. I agree the ANCP solution should allow  
> this. We will work on a revised proposal allowing this.
>
> Francois

As agreed above, below is a proposal for modification to the text of  
draft-ietf-ancp-framework-04.txt in order to accommodate ANCP  
deployment models where the "join/leave" information may not be  
conveyed to NAS via ANCP.
We'd appreciate feedback.
Thanks
Francois

In section 3.4.4:
============

Replace:
"	3.4.4.  Multicast Termination"
by:
"	3.4.4.  Spontaneous Admission Response"

In second paragraph, replace:
"This can be done with the Admission Response message."
by
"This can be achieved by the NAS sending a spontaneous Admission
    Response message (ie sent by NAS without prior receipt of a  
corresponding Admission Request)."

At the end of 3.4.4:
add a new paragraph:
"In some deployment scenarios, the NAS may be made aware of end-users  
requests to join/leave a multicast flow by other means than ANCP  
Admission Requests sent by the AN (for example, the IGMP join/leave  
from the end-user might be somehow tunneled to the NAS). In such  
environments, the NAS can still control multicast replication to be  
performed by the AN via ANCP through the use of spontaneous Admission  
Responses (ie sent by NAS without prior receipt of a corresponding  
Admission Request)."

In section 4.2:
===========

replace:
"   o  The ANCP MUST allow the AN to query the NAS to request an
       admission decision for replicating a multicast flow to a
       particular Access Port."
by
"   o  The ANCP MUST allow the AN to send an Admission Request to the  
NAS to request an
       admission decision for replicating a multicast flow to a  
particular Access Port."

replace:
"   o  The ANCP MUST allow the NAS to send an admission decision to the
       AN indicating whether or not a multicast flow may be  
replicated to
       a particular Access Port."
by
"   o  The ANCP MUST allow the NAS to send an Admission Response to the
       AN (e.g. indicating whether or not a multicast flow is to be  
replicated to
       a particular Access Port).
    o  The ANCP MUST allow the NAS to send such an Admission Response  
either in response to an Admission Request received from the AN or  
spontaneously (i.e. without having received a corresponding Admission  
Request from AN).
    o  In particular, the ANCP MUST allow the NAS to send such an  
Admission Response in order to revoke a decision to replicate a
       multicast flow to a particular Access Port, that had been  
conveyed earlier to an AN.
    o  The ANCP MUST allow the AN to notify the NAS of the outcome  
(success/failure) of a join/leave instruction conveyed in an  
Admission Response from the NAS.
"

replace:
"   o  The ANCP MUST allow the NAS, when replying to an AN request, to
       OPTIONALLY convey information on multiple multicast flows sharing
       the same conditional access rules.  This allows the AN to take
       autonomous decisions for these flows later on."
by:
"   o  The ANCP MUST allow the NAS, when sending an Admission  
Response, to
       OPTIONALLY convey information on multiple multicast flows sharing
       the same conditional access and admission control rules.  This  
allows the AN to take
       autonomous decisions for these flows later on."

delete (this has been replaced by an equivalent requirement above)"
"   o  The ANCP MUST allow the NAS to revoke a decision to replicate a
       multicast flow to a particular Access Port, which had been
       conveyed earlier to an AN."

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 26 Nov 2007 09:34:14 +0100

Hi Francois,

I agree with most of the changes, except one.

If I recall correctly, the idea behind the proposed changes below is to
have a scenario where the Access Node performs replication, but doesn't
perform IGMP processing. In other words, all IGMP report messages (and
likely also all IGMP leave messages) are sent to the NAS; the NAS
instructs the Access Node how to perform the replication by means of
ANCP messages.

On the other hand, the thread issued by Roberta highlights the need to
have mechanisms in place that offload the NAS from having to perform
excessive IGMP and/or ANCP processing. This is done by introducing a
default behavior, guided by filtering lists in the Access Node. In this
solution, the Access Node performs IGMP processing and decides whether
or not to send ANCP messages to the NAS.

I agree with Roberta that a default behavior is in order. So I believe
that IGMP report/leave processing in the Access Node is also a
requirement to achieve a default behavior. Therefore, I would not add
the new paragraph in section 3.4.4.

Some more feedback is inline.

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: donderdag 22 november 2007 14:55
To: Francois Le Faucheur IMAP
Cc: [email-masked]
Subject: Spontaneous Admission Response (was Re: [ANCP] ANCP WG
follow-up)

Hello,

<clip>

> 	2) you raise a valid point that there are ANCP deployment
variations 
> whereby the replication on AN may be controlled by NAS via ANCP, but 
> where the "join/leave" information may not be conveyed to NAS via 
> ANCP. I agree the ANCP solution should allow this. We will work on a 
> revised proposal allowing this.
>
> Francois

As agreed above, below is a proposal for modification to the text of
draft-ietf-ancp-framework-04.txt in order to accommodate ANCP deployment
models where the "join/leave" information may not be conveyed to NAS via
ANCP.
We'd appreciate feedback.
Thanks
Francois

In section 3.4.4:
============

Replace:

<Sven> I am ok with the paragraph text change, but would keep the title
as-is.

At the end of 3.4.4:
add a new paragraph:
"In some deployment scenarios, the NAS may be made aware of end-users
requests to join/leave a multicast flow by other means than ANCP
Admission Requests sent by the AN (for example, the IGMP join/leave from
the end-user might be somehow tunneled to the NAS). In such
environments, the NAS can still control multicast replication to be
performed by the AN via ANCP through the use of spontaneous Admission
Responses (ie sent by NAS without prior receipt of a corresponding
Admission Request)."

<Sven> See above, I don't see a need for these changes.

In section 4.2:
===========

replace:

<Sven> I am ok with this change.

replace:
       AN indicating whether or not a multicast flow may be replicated
to

<Sven> I am ok with this change.

<Sven> I would reword the above two bullets to:

    o  The ANCP MUST allow the NAS to send the Admission Response in
response to an Admission Request received from the AN
    o  The ANCP MUST allow the NAS to send the Admission Response
spontaneously (i.e. without having received a corresponding Admission
Request from AN) in order to revoke a decision to replicate a multicast
flow to a particular Access Port, that had been conveyed earlier to an
AN.

</Sven>

    o  The ANCP MUST allow the AN to notify the NAS of the outcome
(success/failure) of a join/leave instruction conveyed in an Admission
Response from the NAS.
"

<Sven> I am ok with this addition

replace:

<Sven> I am ok with this change

<Sven> I am ok with this removal

Regards,
Sven

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 26 Nov 2007 10:32:30 +0100

Hi Sven,

just an observation; the current text in Section 3.4.4 does not quite
reflect IMO the outcome of the discussion that's been had on the alias,
and hence there is Francois' proposal to modify Section 3.4.4 in order
to allow both spontaneous joins and leaves. Perhaps then, instead of
changing Section 3.4.4 we could create a new section which covers
explicitly the spontaneous join/leave case and includes the proposed
changes?

Regards,
Woj. 

> From: OOGHE Sven [mailto:[email-masked]] 
> Sent: 26 November 2007 09:34
> To: Francois Le Faucheur (flefauch); [email-masked]; Maglione Roberta
> Subject: RE: Spontaneous Admission Response (was Re: [ANCP] 
> ANCP WG follow-up)
> 
> Hi Francois,
> 
> If I recall correctly, the idea behind the proposed changes 
> below is to have a scenario where the Access Node performs 
> replication, but doesn't perform IGMP processing. In other 
> words, all IGMP report messages (and likely also all IGMP 
> leave messages) are sent to the NAS; the NAS instructs the 
> Access Node how to perform the replication by means of ANCP messages.
> 
> On the other hand, the thread issued by Roberta highlights 
> the need to have mechanisms in place that offload the NAS 
> from having to perform excessive IGMP and/or ANCP processing. 
> This is done by introducing a default behavior, guided by 
> filtering lists in the Access Node. In this solution, the 
> Access Node performs IGMP processing and decides whether or 
> not to send ANCP messages to the NAS.
> 
> I agree with Roberta that a default behavior is in order. So 
> I believe that IGMP report/leave processing in the Access 
> Node is also a requirement to achieve a default behavior. 
> Therefore, I would not add the new paragraph in section 3.4.4.
> 
> As agreed above, below is a proposal for modification to the 
> text of draft-ietf-ancp-framework-04.txt in order to 
> accommodate ANCP deployment models where the "join/leave" 
> information may not be conveyed to NAS via ANCP.
>     Response message (ie sent by NAS without prior receipt of 
> a corresponding Admission Request)."
> 
> <Sven> I am ok with the paragraph text change, but would keep 
> the title as-is.
> 
> At the end of 3.4.4:
> add a new paragraph:
> "In some deployment scenarios, the NAS may be made aware of 
> end-users requests to join/leave a multicast flow by other 
> means than ANCP Admission Requests sent by the AN (for 
> example, the IGMP join/leave from the end-user might be 
> somehow tunneled to the NAS). In such environments, the NAS 
> can still control multicast replication to be performed by 
> the AN via ANCP through the use of spontaneous Admission 
> Responses (ie sent by NAS without prior receipt of a 
>        admission decision for replicating a multicast flow to 
>        AN (e.g. indicating whether or not a multicast flow is 
> to be replicated to
>     o  The ANCP MUST allow the NAS to send such an Admission 
> Response either in response to an Admission Request received 
> from the AN or spontaneously (i.e. without having received a 
> corresponding Admission Request from AN).
>     o  In particular, the ANCP MUST allow the NAS to send 
> such an Admission Response in order to revoke a decision to 
> replicate a
>        multicast flow to a particular Access Port, that had 
> been conveyed earlier to an AN.
> 
>     o  The ANCP MUST allow the NAS to send the Admission 
> Response in response to an Admission Request received from the AN
>     o  The ANCP MUST allow the NAS to send the Admission 
> Response spontaneously (i.e. without having received a 
> corresponding Admission Request from AN) in order to revoke a 
> decision to replicate a multicast flow to a particular Access 
> Port, that had been conveyed earlier to an AN.
> 
> </Sven>
> 
>        the same conditional access and admission control 
> rules.  This allows the AN to take

---

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 26 Nov 2007 11:06:02 +0100

Woj,

>From what I can find on the email list, the proposed change to section
3.4.4 is related to the following remark from Sanjay (mid September
2007):

"The option I alluded to is IGMP from RG to BNG, and replication on the
AN. The replication state on the AN created/controlled via ANCP by BNG.
An optimization could be optional transparent snooping of IGMP on the AN
to act on IGMP reports for leave only (to implement "fast leave")."

Now, with the recent discussion on white/black/grey list filtering in
the Access Node, it seems the WG agrees on having mechanisms in place
that reduce the IGMP/ANCP message load on the NAS. A scenario where all
IGMP report messages are sent to the NAS is IMHO in contradiction to the
WG's desire to reduce the NAS load. The Access Node needs to be able to
process IGMP report and leave messages and filter them.

Perhaps Sanjay can explain the scenario in a bit more detail? That way
we can better understand the resulting message load.

Regards,
Sven

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: maandag 26 november 2007 10:33
To: OOGHE Sven; Francois Le Faucheur (flefauch); [email-masked]; Maglione
Roberta
Subject: RE: Spontaneous Admission Response (was Re: [ANCP] ANCP WG
follow-up)

Hi Sven,

Regards,
Woj. 

> Subject: RE: Spontaneous Admission Response (was Re: [ANCP] ANCP WG 
> follow-up)
> 
> Hi Francois,
> 
> If I recall correctly, the idea behind the proposed changes below is 
> to have a scenario where the Access Node performs replication, but 
> doesn't perform IGMP processing. In other words, all IGMP report 
> messages (and likely also all IGMP leave messages) are sent to the 
> NAS; the NAS instructs the Access Node how to perform the replication 
> by means of ANCP messages.
> 

> excessive IGMP and/or ANCP processing.
> This is done by introducing a default behavior, guided by filtering 
> lists in the Access Node. In this solution, the Access Node performs 
> IGMP processing and decides whether or not to send ANCP messages to 
> the NAS.
> 

> requirement to achieve a default behavior.
> deployment models where the "join/leave"
> <Sven> I am ok with the paragraph text change, but would keep the 
> title as-is.
> 
> At the end of 3.4.4:
> add a new paragraph:

> Request from AN) in order to revoke a decision to replicate a 
> multicast flow to a particular Access Port, that had been conveyed 
> earlier to an AN.
> 
> </Sven>
>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 26 Nov 2007 11:42:22 +0100

Hi Sven,

> to act on IGMP reports for leave only (to implement "fast leave")."

Right. This is what initiated the thread.

I am also aware of other planned deployments where the Multicast  
joins are processed by the device behaving as the ANCP-controller (as  
opposed to the AN).

As these ANCP deployments will exist, the ANCP specs ought to  
recognize and allow them. Note that this has very little impact on  
the ANCP protocol anyways (since "spontaneous Admission Responses"  
are already explicitly allowed anyways for multicast termination)

> that reduce the IGMP/ANCP message load on the NAS.

I fail to see the relationship between the recent discussion  
regarding a _default_ for white/black/grey and the ANCP deployment  
models various operators will select.
When IGMP is processed by AN (which I agree is likely to be the  
common model), then we need to agree on a default in case of no-match  
in white/black/grey. This choice has no bearing on how operators will  
distribute functions across AN and NAS for different multicast flows.  
The only impact on selecting a default vs another is on  
configuration. And it is a very minor configuration impact since we  
are only talking about one extra single catch-all entry in one list.

> A scenario where all
> WG's desire to reduce the NAS load.

The WG has already concluded on the debate about perceived need "to  
reduce the NAS load" when considering the Grey List. I believe the  
conclusion was that while some perceive it is desirable to reduce the  
NAS load as much as possible, a significant part of the WG felt it is  
desirable to be able to take advantage of NAS capabilities for  
replication control. As a result, the WG decided that ANCP ought to :
	- allow operation where replication control is done in AN,
	- also allow operation where replication control is done by NAS  
(hence the notion of Grey lists).

The current ANCP framework already allows replication control to be  
done by the NAS (where NAS is made aware of join/leave via ANCP  
Admission Requests).
The proposal below only aims at allowing another deployment model  
where replication control is done by NAS (this time where NAS is made  
aware of join/leave by other means than ANCP) .

Cheers

Francois

> The Access Node needs to be able to
>> replicated
>> Admission

---

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 26 Nov 2007 13:10:39 +0100

Francois, 

see inline.

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: maandag 26 november 2007 11:42
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); [email-masked];
Maglione Roberta
Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG
follow-up)

Hi Sven,

On 26 Nov 2007, at 11:06, OOGHE Sven wrote:

> "The option I alluded to is IGMP from RG to BNG, and replication on 
> the AN. The replication state on the AN created/controlled via ANCP by

> BNG.
> An optimization could be optional transparent snooping of IGMP on the 
> AN to act on IGMP reports for leave only (to implement "fast leave")."

I am also aware of other planned deployments where the Multicast joins
are processed by the device behaving as the ANCP-controller (as opposed
to the AN).

As these ANCP deployments will exist, the ANCP specs ought to recognize
and allow them. Note that this has very little impact on the ANCP
protocol anyways (since "spontaneous Admission Responses"  
are already explicitly allowed anyways for multicast termination)

> that reduce the IGMP/ANCP message load on the NAS.

I fail to see the relationship between the recent discussion regarding a
_default_ for white/black/grey and the ANCP deployment models various
operators will select.

When IGMP is processed by AN (which I agree is likely to be the common
model), then we need to agree on a default in case of no-match in
white/black/grey. 
This choice has no bearing on how operators will distribute functions
across AN and NAS for different multicast flows.  
The only impact on selecting a default vs another is on configuration.
And it is a very minor configuration impact since we are only talking
about one extra single catch-all entry in one list.

<Sven> I'm not disagreeing here. All I am saying is that based on the
previous threads, I believe the conclusion was that we need some form of
IGMP report message processing in the Access Node in order to reduce the
load on the NAS. In other words, in a model where the Access Node would
send IGMP messages to the NAS without processing - which is what you
would like to add - one would still use ANCP to send information of
other multicast groups to the AN, so that the AN can perform IGMP
processing for subsequent reports.
</Sven>

> A scenario where all
> IGMP report messages are sent to the NAS is IMHO in contradiction to 
> the WG's desire to reduce the NAS load.

<Sven> I understood the conclusion was that it is desirable to reduce
the NAS load, while also supporting mechanisms for the NAS to control
replication. Blindly forwarding all IGMP reports to the NAS, followed by
ANCP to the AN seems to contradict this. There needs to be some way to
reduce the load (see above remark).

The current ANCP framework already allows replication control to be done
by the NAS (where NAS is made aware of join/leave via ANCP Admission
Requests).
The proposal below only aims at allowing another deployment model where
replication control is done by NAS (this time where NAS is made aware of
join/leave by other means than ANCP) .

Cheers

Francois

Regards,
Sven

> To: OOGHE Sven; Francois Le Faucheur (flefauch); [email-masked]; 
> Maglione Roberta
> reflect IMO the outcome of the discussion that's been had on the 
> alias, and hence there is Francois' proposal to modify Section 3.4.4 
> in order to allow both spontaneous joins and leaves. Perhaps then, 
> instead of changing Section 3.4.4 we could create a new section which 
> covers explicitly the spontaneous join/leave case and includes the 
> proposed changes?
>
> Regards,
> Woj.
>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 26 Nov 2007 13:31:47 +0100

Sven, All,

inline... 

> Sent: 26 November 2007 13:11
> To: Francois Le Faucheur (flefauch)
> Cc: Wojciech Dec (wdec); [email-masked]; Maglione Roberta
> Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); 
> [email-masked]; Maglione Roberta
> I am also aware of other planned deployments where the 
> Multicast joins are processed by the device behaving as the 
> ANCP-controller (as opposed to the AN).
> 
> recognize and allow them. Note that this has very little 
> impact on the ANCP protocol anyways (since "spontaneous 
> Admission Responses"  
> regarding a _default_ for white/black/grey and the ANCP 
> deployment models various operators will select.
> 
> When IGMP is processed by AN (which I agree is likely to be 
> the common model), then we need to agree on a default in case 
> of no-match in white/black/grey. 
> This choice has no bearing on how operators will distribute 
> functions across AN and NAS for different multicast flows.  
> And it is a very minor configuration impact since we are only 
> talking about one extra single catch-all entry in one list.
> 
> <Sven> I'm not disagreeing here. All I am saying is that 
> based on the previous threads, I believe the conclusion was 
> that we need some form of IGMP report message processing in 
> the Access Node in order to reduce the load on the NAS. In 
> other words, in a model where the Access Node would send IGMP 
> messages to the NAS without processing - which is what you 
> would like to add - one would still use ANCP to send 
> information of other multicast groups to the AN, so that the 
> AN can perform IGMP processing for subsequent reports.
> </Sven>

Woj> Agreed, noting however that this refers  a specific IGMP deployment
scenario.

> The WG has already concluded on the debate about perceived 
> need "to reduce the NAS load" when considering the Grey List. 
> I believe the conclusion was that while some perceive it is 
> desirable to reduce the NAS load as much as possible, a 
> significant part of the WG felt it is desirable to be able to 
> take advantage of NAS capabilities for replication control. 
> As a result, the WG decided that ANCP ought to :
> 	- also allow operation where replication control is 
> done by NAS (hence the notion of Grey lists).
> 
> <Sven> I understood the conclusion was that it is desirable 
> to reduce the NAS load, while also supporting mechanisms for 
> the NAS to control replication. Blindly forwarding all IGMP 
> reports to the NAS, followed by ANCP to the AN seems to 
> contradict this. There needs to be some way to reduce the 
> load (see above remark).

Woj> Sanjay's mail raised a valid observation about alternative
deployment scenarios, where IGMP processing on the AN is disabled. One
should generalise this argument further and totally decouple it from
IGMP - the proposed spontaneous control mechanism provides such
decoupling. The evaluation of what load can a NAS handle depends on
numerous other factors than just IGMP processing, and should not be the
only goal for laying down the requirements ANCP functionality. In terms
of such functionality thus, ANCP should be capable of addressing
multicast deployment scenarios decoupled from IGMP assumptions. I see
the proposal as one filling this gap.

-Woj.

> 
> The current ANCP framework already allows replication control 
> to be done by the NAS (where NAS is made aware of join/leave 
> via ANCP Admission Requests).
> The proposal below only aims at allowing another deployment 
> model where replication control is done by NAS (this time 
> where NAS is made aware of join/leave by other means than ANCP) .
> 
> Cheers
> 
> Francois
> 
> Regards,
> Sven
> 
> the need 
> filtering 
> Response in 
> rules.  This

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 26 Nov 2007 14:43:07 +0100

Sven, Woj,

> the proposal as one filling this gap.

<Francois> The proposal submitted on the alias leaves it entirely  
open as to how the join/leave information is conveyed to NAS.
It mentions tunneling IGMP joins/leaves to the NAS purely as an example.
Alternatively, it could be done by sending IGMP Join/Leaves to both  
the NAS and the AN (and have NAS use this as a trigger to push to AN  
authorisation for a group of flows sharing same conditional/admission  
control rules - and then have AN do autonomous decision within the  
group and possibly also process leaves).
Alternatively, it could be done using another protocol than IGMP.

Is it not acceptable to leave this open so ANCP allows all these  
deployment models (particularly considering it does not seem to  
require any extra extensions to ANCP: all we need is the Spontaneous  
Admission Response).
Why would we prevent some of these deployment models?

Perhaps we could change the wording in order to:
	* make it very clear that tunneling IGMP join/leave to NAS is just  
an example deployment model
	* there are other deployment models
	* describe another deployment model along the lines of what Sven  
discussed (ie I think with NAS doing some initial processing and then  
AN doing subsequent processing, eg using the concept that we used to  
call "flow-group").

How does that sound?

Francois

---

From: "Jerome Moisand" <[email-masked]>
Date: Mon, 26 Nov 2007 17:20:01 -0500

A few comments from an "old ghost"... ;-)

<< The option I alluded to is IGMP from RG to BNG, and replication on
the AN. The replication state on the AN created/controlled via ANCP by
BNG. >>

Just an historical reminder. The scenario where the BNG is the "ANCP
controller" (i.e. processes all multicast join/leaves, and instructs the
Access Node to establish replication rules) was the scenario which
triggered the entire DSL-Forum L2-control initiative a few years ago...
Then we collectively started to focus on other priorities, but this
scenario remains very valid.

There are multiple advantages to this scenario, like:
1. full flexibility and AN independence from the multicast control
protocol and its encapsulation (could be IGMP over PPP, could be IGMP
over IPSec, could be SIP Invites, could be an external app server
driving the BNG to delegate replication, could be an IPv6 control
protocol, could also be an ATM aggregation scenario -yes, this still
exists!-, whatever)
2. full visibility by the BNG about the multicast changes in the proper
subscriber context, so dynamically deciding to optimize multicast or
not, adjusting hierarchical QoS or subscriber statistics, or making
local CAC decisions becomes much easier for the BNG (as opposed to more
contorted schemes discussed in the past)
3. overall behavior becoming 100% consistent with scenarios without
multicast optimization.

As to the BNG IGMP load, well, I believe this is up to BNG vendors reps
to speak up here, and working for one such vendor, I have never seen it
as an show stopper to address some major use cases, and never viewed
L2C/ANCP as a necessary mean to 'reduce IGMP load'. This point was
emphasized again & again in the DSL-Forum years ago.

So... fully agreed with Francois and Woj, the "spontaneous admission
response" scenario should definitely be covered. Low cost and high
return on investment! ;-)

Cheers,
Jerome - back to ghost mode 

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: Monday, November 26, 2007 8:43 AM
To: OOGHE Sven; Wojciech Dec (wdec)
Cc: [email-masked]
Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG
follow-up)

Sven, Woj,

	* make it very clear that tunneling IGMP join/leave to NAS is
just  

How does that sound?

Francois

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 27 Nov 2007 14:54:23 +0100

Francois, all,

Ok, so how about we write the following paragraph at the end of section
3.4.4 (modified text from your proposal):

"In some deployment scenarios, the NAS may be made aware of end-users
requests to join/leave a multicast flow by other means than ANCP
Admission Requests sent by the AN. One possible deployment scenario
where this model applies is the case where the Access Node doesn't
process the IGMP join/leave messages from the end-user (e.g. because
they are tunneled), but forwards them to the NAS. In such environments,
the NAS can control multicast replication on the AN via ANCP through the
use of Spontaneous Admission Responses (i.e. sent by the NAS without
prior receipt of a corresponding Admission Request)."

How does that sound?

Regards,
Sven

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: maandag 26 november 2007 14:43
To: OOGHE Sven; Wojciech Dec (wdec)
Cc: Francois Le Faucheur IMAP; [email-masked]; Maglione Roberta
Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG
follow-up)

Sven, Woj,

>> reduce the NAS load" when considering the Grey List.
>> I believe the conclusion was that while some perceive it is desirable

>> to reduce the NAS load as much as possible, a significant part of the

>> WG felt it is desirable to be able to take advantage of NAS 
>> capabilities for replication control.

>> replication. Blindly forwarding all IGMP reports to the NAS, followed

>> by ANCP to the AN seems to contradict this. There needs to be some 
>> way to reduce the load (see above remark).
>

> numerous other factors than just IGMP processing, and should not be 
> the only goal for laying down the requirements ANCP functionality. In 
> terms of such functionality thus, ANCP should be capable of addressing

> the proposal as one filling this gap.

<Francois> The proposal submitted on the alias leaves it entirely open
as to how the join/leave information is conveyed to NAS.
It mentions tunneling IGMP joins/leaves to the NAS purely as an example.
Alternatively, it could be done by sending IGMP Join/Leaves to both the
NAS and the AN (and have NAS use this as a trigger to push to AN
authorisation for a group of flows sharing same conditional/admission
control rules - and then have AN do autonomous decision within the group
and possibly also process leaves).
Alternatively, it could be done using another protocol than IGMP.

Is it not acceptable to leave this open so ANCP allows all these
deployment models (particularly considering it does not seem to require
any extra extensions to ANCP: all we need is the Spontaneous Admission
Response).
Why would we prevent some of these deployment models?

Perhaps we could change the wording in order to:
	* make it very clear that tunneling IGMP join/leave to NAS is
just an example deployment model
	* there are other deployment models
	* describe another deployment model along the lines of what Sven
discussed (ie I think with NAS doing some initial processing and then AN
doing subsequent processing, eg using the concept that we used to call
"flow-group").

How does that sound?

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 27 Nov 2007 16:03:39 +0100

> prior receipt of a corresponding Admission Request)."

That works for me.

I assume 3.4.4 title would be changed accordingly to something like  
"3.4.4 Spontaneous Admission Responses".

Cheers

Francois

>>> desirable
> the
> require

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 27 Nov 2007 16:20:18 +0100

Francois,

The title would need to be changed, correct. 

Regards,
Sven

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: dinsdag 27 november 2007 16:04
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); [email-masked];
Maglione Roberta

On 27 Nov 2007, at 14:54, OOGHE Sven wrote:

> they are tunneled), but forwards them to the NAS. In such 
> environments, the NAS can control multicast replication on the AN via 
> ANCP through the use of Spontaneous Admission Responses (i.e. sent by 
> the NAS without prior receipt of a corresponding Admission Request)."
>
> How does that sound?

That works for me.

Cheers

Francois

> 	* make it very clear that tunneling IGMP join/leave to NAS is
just an 
> example deployment model