Subject: [ANCP] ANCP WG follow-up

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Mon, 3 Sep 2007 14:38:41 +0200

Hi All,

At the recent IETF meeting we've heard a fair amount of debate regarding
the subject of multicast. The debate spanned multiple camps and went
over both the whys, the why not's, as well as pros and cons. The general
consensus formed at the meeting was that the framework and requirements
document needs to cover all use cases to the same level of depth, and to
have sufficient detail to design the protocol. This in effect means the
definition of the message primitives for supporting the use-case(s). 
We also heard there being significantly more support than not for
introducing into the protocol the flexibility offered by the
request-response message set as proposed in draft-maglione, along with
the use-cases. Hence, we would like to confirm the following direction
with the working group for carrying out the following two points:

1. Introduce into the latest draft-ietf-ancp-framework changes and text
that covers the following:
- High level message diagram including query/response primitives
- Description of the following multicast-use cases; 
* Multicast Conditional Access
* Multicast Admission Control
* Multicast Accounting
* Multicast Termination

Some solidification of the final text will be required and ought to take
place on the alias. For the above however draft-maglione appears to
contain a fair base of the material required.

2. The WG commences work on defining the necessary protocol extensions
for inclusion in draft-ietf-ancp-protocol, based on the protocol
specific text in draft-maglione.

Regards,
Woj and Matthew.

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

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 4 Sep 2007 00:49:30 -0400

Woj/Matthew
   There was some support for multicast use-cases in general amongst the
folks who were in attendence at the last WG meeting. However, specifally
on draft-maglione, while it sets good context for the multicast use
cases, the mechanism (and corresponding message flows) suggested in the
draft only cover a single deployment scenario. It does not cover the
case where the AN does not do or is incapable of IGMP snooping, and the
BNG controls the replication on the AN via ANCP. 
Adding general text on multicast use-cases (conditional
access/CAC/accounting) in the framework draft is fine. However, choosing
a single deployment model, and adding message flows for it in the
framework draft, is not ideal. 
Also, there were specific questions raised on the mailing list on some
of the suggestions in the draft (specifically pertaining to flow-group
optimization). We haven't seen any responses. 
IMHO, we need to make progress on both these fronts (describing
alternate deployment model, and providing clarity on mechanisms defined
in draft-maglione) before we can make progress on adding detailed
message flows and corresponding protocol machinery to framework and
protocol drafts.

Regards
-Sanjay                              

>-----Original Message-----
>From: Wojciech Dec (wdec) [mailto:[email-masked]]
>Sent: Monday, September 03, 2007 8:39 AM
>To: [email-masked]
>Subject: [ANCP] ANCP WG follow-up
>
>
>Hi All,
>

---

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Tue, 4 Sep 2007 13:02:33 +0200

Sanjay,

The points you raise regarding more specifics around flow groups are
fine, and should take place on the alias as part of the work on the
protocol draft text.
Also for scenarios where the AN is not capable of for example IGMP
processing (which is precisely the functional model you seem to say
needs to be added), feel free to propose for discussion the use-case and
a mechanism that fits with the draft-maglione proposal.

As a side-note: I do remember hearing from several group participants
opinions that "legacy ATM" use-cases (and non IGMP capable access-nodes
could likely fall in that category) should be placed on a lower footing
than the others in relation to new use-cases. The complexity of any
mechanism aimed at supporting these use-cases in this category vs their
benefit needs to be one of the considerations for the WG. 

Regards,
Woj.

> From: Sanjay Wadhwa [mailto:[email-masked]] 
> Sent: 04 September 2007 06:50
> To: Wojciech Dec (wdec); [email-masked]; 
> [email-masked]
> Subject: RE: [ANCP] ANCP WG follow-up
> 
> Woj/Matthew
>    There was some support for multicast use-cases in general 
> amongst the folks who were in attendence at the last WG 
> meeting. However, specifally on draft-maglione, while it sets 
> good context for the multicast use cases, the mechanism (and 
> corresponding message flows) suggested in the draft only 
> cover a single deployment scenario. It does not cover the 
> case where the AN does not do or is incapable of IGMP 
> snooping, and the BNG controls the replication on the AN via ANCP. 
> access/CAC/accounting) in the framework draft is fine. 
> However, choosing a single deployment model, and adding 
> message flows for it in the framework draft, is not ideal. 
> Also, there were specific questions raised on the mailing 
> list on some of the suggestions in the draft (specifically 
> pertaining to flow-group optimization). We haven't seen any 
> responses. 
> IMHO, we need to make progress on both these fronts 
> (describing alternate deployment model, and providing clarity 
> on mechanisms defined in draft-maglione) before we can make 
> progress on adding detailed message flows and corresponding 
> protocol machinery to framework and protocol drafts.
> 
> Regards
> -Sanjay                              
> 
> >At the recent IETF meeting we've heard a fair amount of debate 
> >regarding the subject of multicast. The debate spanned 
> multiple camps 
> >and went over both the whys, the why not's, as well as pros and cons.
> >The general
> >document needs to cover all use cases to the same level of 
> depth, and 
> >to have sufficient detail to design the protocol. This in 
> effect means 
> >the definition of the message primitives for supporting the 
> >use-case(s).
> >Some solidification of the final text will be required and ought to 
> >take place on the alias. For the above however 
> draft-maglione appears 
> >to contain a fair base of the material required.
> >

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 4 Sep 2007 09:17:55 -0400

Woj
  There are questions with the flow-group concept (and other mechanisms
in the draft), that have already been raised in email threads. Since you
are suggesting, the framework document should contain message flows for
a specific solution, it needs to be made sure that the solution is a
workable solution, and does not ignore viable deployment options, before
we do anything with the framework draft. Ideally, the framework draft
should not contain message flows for a specific solution/implementation.

On the second issue, IGMP snooping capability or lack of (for both IP
and PPP) on an "AN" or the necessity for a deployment to use it, if
supported, has nothing to do with ATM or Ethernet. By lumping these
together one could conveniently ignore viable deployment scenarios,
which is not justified. 
There are tier-1 deployments today, where the replication as well as all
the necessary multicast control happens on the BNG. It is desirable to
move the replication to the AN. However, this should not come with the
need and complexity to move all the necessary multicast control
processing to the AN.

The use-cases for both models are the same (conditional access,
multi-service CAC, accounting etc). The message-flows, *complexity* and
the extent to which ANCP is leveraged in each case is different. 

Regards
-Sanjay

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2007 7:03 AM
To: Sanjay Wadhwa; [email-masked]; [email-masked]
Subject: RE: [ANCP] ANCP WG follow-up

Sanjay,

Regards,
Woj.

---

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Wed, 5 Sep 2007 12:43:02 +0200

Sanjay,

The framework document is the place to define the message primitives and
use-cases - this is intended not to drive any specific solution but
rather the overall fundamental protocol messaging capability. I would
also like to point out that this is not *my* suggestion, but rather the
conclusion reached by the WG at the meeting. 
Flow groups or not, the primitives that appear to be required for the
multicast case(s) are the Request/Response ones (see Figure 1 of the
ancp-framework document for an example of other primitives). So, to
re-iterate the direction for the WG is to; 
* include in the framework document such message primitives and a
description of the use-cases. 
* Work on message specifics for protocol draft. 
In the above review and comments on the specific text for each of the
drafts will take place as usual though discussion on the alias.

Now let's delve into the two specific issues you raise and open up the
discussion to the WG as a whole:

1. The flow-group concept is generally understood to be an intended to
reduce/optimize the number of ANCP messaging transactions subject to
certain conditions related to the multicast-use case(s). This seems to
be a worthwhile goal, and even though the current flow-group text is not
perfect and protocol details are not sufficient, there is no other
optimization mechanism on the table. It's clearly up to further debate
by the WG on how the optimization behaviour should be realized in
protocol specifics, eg by using a type-of-Response message, or though a
change-of-configuration message.

Now, could you, or anyone present an alternative proposal for such
optimization? Or are you objecting to the whole concept?

2. Alternative Deployment scenarios.
Can you please prepare a *concrete proposal* regarding the scenario you
describe, and the modifications to the high-level (primitives) mechanism
in draft-maglione required to support it? Before this is presented,
saying that there are other "viable deployment scenarios" is not very
constructive and doesn't allow the WG to make an assessment on what to
do with it.

Regards,
Woj.

> Sent: 04 September 2007 15:18
>   There are questions with the flow-group concept (and other 
> mechanisms in the draft), that have already been raised in 
> email threads. Since you are suggesting, the framework 
> document should contain message flows for a specific 
> solution, it needs to be made sure that the solution is a 
> workable solution, and does not ignore viable deployment 
> options, before we do anything with the framework draft. 
> Ideally, the framework draft should not contain message flows 
> for a specific solution/implementation.
> 
> On the second issue, IGMP snooping capability or lack of (for 
> both IP and PPP) on an "AN" or the necessity for a deployment 
> to use it, if supported, has nothing to do with ATM or 
> Ethernet. By lumping these together one could conveniently 
> ignore viable deployment scenarios, which is not justified. 
> There are tier-1 deployments today, where the replication as 
> well as all the necessary multicast control happens on the 
> BNG. It is desirable to move the replication to the AN. 
> However, this should not come with the need and complexity to 
> move all the necessary multicast control processing to the AN.
> 
> The use-cases for both models are the same (conditional 
> access, multi-service CAC, accounting etc). The 
> message-flows, *complexity* and the extent to which ANCP is 
> leveraged in each case is different. 
> 
> Regards
> -Sanjay
> 
> The points you raise regarding more specifics around flow 
> groups are fine, and should take place on the alias as part 
> of the work on the protocol draft text.
> Also for scenarios where the AN is not capable of for example 
> IGMP processing (which is precisely the functional model you 
> seem to say needs to be added), feel free to propose for 
> discussion the use-case and a mechanism that fits with the 
> draft-maglione proposal.
> 
> As a side-note: I do remember hearing from several group 
> participants opinions that "legacy ATM" use-cases (and non 
> IGMP capable access-nodes could likely fall in that category) 
> should be placed on a lower footing than the others in 
> relation to new use-cases. The complexity of any mechanism 
> aimed at supporting these use-cases in this category vs their 
> >    There was some support for multicast use-cases in 
> general amongst 
> > the folks who were in attendence at the last WG meeting. However, 
> > specifally on draft-maglione, while it sets good context for the 
> > multicast use cases, the mechanism (and corresponding 
> message flows) 
> > suggested in the draft only cover a single deployment scenario. It 
> > does not cover the case where the AN does not do or is incapable of 
> > IGMP snooping, and the BNG controls the replication on the AN via 
> > ANCP.
> message flows 
> > for it in the framework draft, is not ideal.
> list on some 
> > alternate deployment model, and providing clarity on mechanisms 
> > defined in draft-maglione) before we can make progress on adding 
> > detailed message flows and corresponding protocol machinery to 
> > framework and protocol drafts.
> > 
> > Regards
> > -Sanjay                              
> >

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Wed, 5 Sep 2007 16:39:04 -0400

Woj
 Framework draft needs to contain requirements and use-cases for ANCP.
This is the model used until now in the framework draft. There is a
single high-level communication flow (figure 1) for ANCP mechanism in
general. This is equally applicable to multicast use-case. As you will
notice, there is no other use-case specific message exchange in the
framework draft. 
Adding message flows from draft-maglione to the framework draft is
solution-creep, which has been avoided until now. Message flows in
draft-maglione are tied to the proposed solution. As an example consider
the message flow in figure 9 from the draft. It is related to the
suggested solution as it refers to flow-groups in message exchange. 

With respect to #1 in your mail below, I am not opposed to any
optimizations aimed at reducing message load. However, the optimization
as a concept has to gurantee correctness and simplicity, both of which
are independent of the protocol messages used to implement the concept.
A more constructive approach would be for the authors of the draft to
consider issues raised thus far to ensure a workable solution, before
any push from WG chair for inclusion of content into the framework
draft.

With respect to #2, draft-maglione requires/mandates IGMP snooping and
full IGMP control on the AN, which is a valid option. However, we also
need to consider the option where the AN does the replication, but is
not burdened with all the associated IGMP control. And again this has
nothing to do with ATM or Ethernet in the aggregation network.
The concreate proposal is for the "Home Gateway" to send per-subscriber
IGMP to the BNG, which triggers per-subscriber conditional-access,
admission-control, and accounting on the BNG. If both access and
admission control passes, the BNG can use ANCP to set multicast
replication state on the AN. 
A variation here could be that the AN transparently snoops, but
autonomously acts on IGMP leaves to implement a "fast leave". However,
the creation of the replication state on AN is still controlled by the
BNG via ANCP, subject to access and admission control. 

Regards
-Sanjay

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 6:43 AM
To: Sanjay Wadhwa; [email-masked]; [email-masked]
Subject: RE: [ANCP] ANCP WG follow-up

Sanjay,

Regards,
Woj.

> mechanisms in the draft), that have already been raised in email 
> threads. Since you are suggesting, the framework document should 
> contain message flows for a specific solution, it needs to be made 
> sure that the solution is a workable solution, and does not ignore 
> viable deployment options, before we do anything with the framework 
> draft.
> Ideally, the framework draft should not contain message flows for a 
> specific solution/implementation.
> 
> There are tier-1 deployments today, where the replication as well as 
> all the necessary multicast control happens on the BNG. It is 
> desirable to move the replication to the AN.
> However, this should not come with the need and complexity to move all

> the necessary multicast control processing to the AN.
> 
> multi-service CAC, accounting etc). The message-flows, *complexity* 
> and the extent to which ANCP is leveraged in each case is different.
> 
> Regards
> -Sanjay
> 
> needs to be added), feel free to propose for discussion the use-case 
> and a mechanism that fits with the draft-maglione proposal.
> 
> opinions that "legacy ATM" use-cases (and non IGMP capable 
> access-nodes could likely fall in that category) should be placed on a

> lower footing than the others in relation to new use-cases. The 
> complexity of any mechanism aimed at supporting these use-cases in 
> this category vs their benefit needs to be one of the considerations 
> for the WG.
> 
> Regards,
> Woj.
>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 6 Sep 2007 12:24:40 +0200

Hi Sanjay,

> notice, there is no other use-case specific message exchange in the

Very true.
But as you will notice, the primitives and parameters are indeed  
defined in the framework for each use case.

Example of primitives discussed include:
" The NAS may then use the Configure Request message to send a  
reference to the
    right profile to the Access Node.  The NAS may also update the  
Access
    Loop configuration due to a Subscriber service change (e.g.  
triggered
    by the policy server)."

Example of parameters listed for these primitives include:
" In case of DSL Access  Loops, the following Access Loop  
characteristics can be sent to the
    NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]):
    o  DSL Type (e.g.  ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2)
    o  Framing mode (e.g.  ATM, ITU-T Packet Transfer Mode (PTM), IEEE
       802.3 Ethernet in the First Mile (EFM))
    o  DSL port state (e.g. synchronized/showtime, low power, no power/
       idle)
    o  Actual net data rate (upstream/downstream)
    o  Maximum achievable/attainable data rate (upstream/downstream)
    o  Minimum data rate configured for the Access Loop (upstream/
       downstream)
    o  Maximum data rate configured for the Access Loop (upstream/
       downstream)
    o  Minimum data rate in low power state configured for the Access
       Loop (upstream/downstream)
    o  Maximum achievable interleaving delay (upstream/downstream)
    o  Actual interleaving delay (upstream/downstream)
"

> the message flow in figure 9 from the draft.

The topic of "what belongs to the framework draft and what belongs to  
the protocol draft" has come up before. I believe the agreed  
conclusion is:
	* the framework document ought to include:
		(1) requirements
		(2) use-cases
		(3) primitives/parameters (REPEAT: primitives and parameters)
	* the protocol document ought to include:
		(1) actual message flows.
This is what has been done for all the existing use cases in the  
current framework.
I believe this is what we have also re-established during the Chicago  
meeting.

Do you agree with this breakout?

draft-maglione explicitly says:
"This proposal aims at collecting feedback from this community in  
order to work towards consensus. Eventually, text derived from the
    material in section 3. and 4. would be intended to be  
incorporated in "ANCP Framework I-D" [1]. Similarly, text derived  
from the material
    of section 5. would be intended to be incorporated in "ANCP  
Protocol I-D" [2] and to be extended with actual protocol extensions.
"
So it is NOT proposing to incorporate message flows (such as the one  
in figure 9) into the framework, but rather into the protocol document.

In his message below, while Woj is proposing that primitives/ 
parameters be included into the framework, he is NOT proposing that  
message flows be incorporated into the framework.

Is it clear to you now that neither the draft-maglione co-authors nor  
Woj are trying to push any message flow into the framework?

> It is related to the

Yes, we need to further discuss the comments/suggestions brought up  
on the list on the primitives discussed in draft-maglione before they  
can be incorporated in the framework document. We'll try get onto  
this soon, and see if we can work towards some converged approach.

> not burdened with all the associated IGMP control.

If the WG decides to incorporate that approach into the framework  
also, a possible approach could be to try make the draft-maglione  
approach more explicitly modular whereby one could either :
	- deploy the full ANCP solution : ie ANCP for relaying leave/join  
from AN to BNG + ANCP for controlling replication by BNG, or
	- hybrid solution: ie IGMP for relaying leave/join from AN to BNG +  
ANCP for controlling replication by BNG

It would be good to hear other opinions from WG about whether we need  
to do this.

Cheers

Francois

> And again this has

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 18 Sep 2007 17:36:44 -0400

Francois
  Reviving the thread... Please see inline. 

>From: Francois Le Faucheur IMAP [mailto:[email-masked]]
>Sent: Thursday, September 06, 2007 6:25 AM
>To: Sanjay Wadhwa
>Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); [email-masked];
>Subject: Re: [ANCP] ANCP WG follow-up
>
>
>Hi Sanjay,
>
>>

I don't think we are dis-agreeing. However, I want to clarify the
following (at the risk of repeating). 
Draft-maglione defines one possible option/architecture for multicast,
where per-subscriber IGMP terminates on the DSLAM. It is reasonable for
the framework draft to describe this as *one* of the possible options
for multicast, and for this option, it is also reasonable to define
high-level exchange between AN and BNG to implement each of the
use-cases (e.g. it is reasonable to say and "Admission-Control-Request"
in ANCP will be sent from AN to BNG on reception of IGMP). 
One would assume the same level of detail goes in for other
alternate/viable options/architectures for multicast. 

>in figure 9) into the framework, but rather into the protocol document.

I was hoping the base description of use-cases that are added into the
framework draft remain generic i.e. not tied to a specific
option/architecture. For example text in section 3 of draft-maglioine
defines the use-cases assuming per-subscriber IGMP is terminated on the
AN. Ideally, we should have a section that defines the basic use-cases
in a generic manner, and then add anything that is specific to a
paritcular multicast option in a sub-section specific to that option.
Same goes for section 4 of the draft. It assumes a particular multicast
architecture and goes into the details (including optimizations) for
that architecture.

>ANCP for controlling replication by BNG

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"). 

Thanks
-Sanjay

>participants

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 19 Sep 2007 15:56:01 +0200

Sanjay and all,

On 18 Sep 2007, at 23:36, Sanjay Wadhwa wrote:

>   Reviving the thread...

Good.

I think the gist of the discussion below is :

	1) there is agreement that "primitives & parameters" belong to  
Framework I-D, that "call flows" belong to Protocol I-D, and that  
draft-maglione proposal is exactly in line with such a break-out

	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

> Please see inline.
>>>> well as