Subject: [ANCP] [Fwd: I-D ACTION:draft-ietf-ancp-mc-extensions-01.txt]

From: Tom Taylor <[email-masked]>
Date: Tue, 27 Oct 2009 13:01:41 -0400

This was a major rewrite. One part is evidenced by the abstract -- the 
modification of the capabilities. The Multicast Status message was removed and 
put into the base protocol as the Generic response message. We refined the 
control of admission control at the AN for different classes of stream. I can 
provide a detailed list of changes, but this will take a little while.

Francois had a hand in getting the main ideas into shape, but due to 
circumstances on my side he didn't have a chance to read and approve the final 
version of the draft. Roberta is not currently accessible. So I take 
responsibility for any deficiencies and stand ready to correct them as directed 
by the WG.

Tom Taylor

-------- Original Message --------
Subject: [ANCP] I-D ACTION:draft-ietf-ancp-mc-extensions-01.txt
Date: Tue, 27 Oct 2009 09:45:01 -0700 (PDT)
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Access Node Control Protocol Working Group of 
the IETF.

	Title		: Additional Multicast Control Extensions for ANCP
	Author(s)	: F. Le Faucheur, R. Maglione, T. Taylor
	Filename	: draft-ietf-ancp-mc-extensions-01.txt
	Pages		: 91
	Date		: 2009-10-27
	
This document specifies the extensions to the Access Node Control
    Protocol required for support of the multicast use cases defined in
    the Access Node Control Protocol framework document.  Those use cases
    are organized into the following ANCP capabilities:

    o  NAS-initiated multicast replication;

    o  conditional access with white and black lists;

    o  conditional access with grey lists;

    o  bandwidth delegation.

    These capabilities may be combined according to the rules given in
    this specification.

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 28 Oct 2009 16:43:27 +0100

Tom and all,

> circumstances on my side he didn't have a chance to read and approve  
> the final version of the draft.

I reviewed the final text of section 6. In general, it is in line with  
the discussions & conclusions Tom and I had.

Below are a the most important comments that I'd like to make sure we  
agree on:

* 6.2.1. The case where CAC is done on NAS is clearly implied but not  
explicit. I think we want to be explicit about it. So I propose:
REPLACE:
"The NAS MAY enable admission control at the AN for Nas-initiated  
replication.  To do this, it MUST include the MRepCtl-CAC TLV in a  
Provisioning message sent to the AN.  It MUST also include a Bandwidth- 
Allocation TLV in a Port Management message for each access line.
"
BY:
"The NAS MAY perform admission control of the NAS-initiated  
replication. Alternatively, the NAS MAY enable admission control at  
the AN for NAS-initiated replication.  To do this, it MUST include the  
MRepCtl-CAC TLV in a Provisioning message sent to the AN and it MUST  
include a Bandwidth-Allocation TLV in a Port Management message for  
each access line.
"

* 6.2.3.1. The case where CAC is done on NAS is clearly implied but  
not explicit. I think we want to be explicit about it. So I propose:
REPLACE:
"The NAS can enable admission control at the AN for Grey-listed flows.  
To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning  
message sent to the AN.  It MUST also provide a Bandwidth-Allocation  
TLV in a Port Management message for each access line.
"
BY:
"The NAS MAY perform admission control for grey-listed flows.  
Alternatively, the NAS MAY enable admission control at the AN for Grey- 
listed flows. To do this, it MUST include the MRepCtl-CAC TLV in a  
Provisioning message sent to the AN and MUST also provide a Bandwidth- 
Allocation TLV in a Port Management message for each access line.
"

* Result Codes
On Tom's proposal, -01 reverted to using Result values AckAll & NAck  
instead of Ignore (as was done in previous versions) with a few  
commands where AckAll & NAck seem ed to match teh desired response  
behavior. I don't feel strongly about that, but want to point out this  
is a departure from what was agreed before and I am requesting WG  
opinions on that.

* Response to Multicast Replication Control:
This comment assumes that the WG agrees that Results AckAll & NAck is  
the right approach for some commands like Multicast Replication Control.
Tom and I agreed that the NAS decides whether to use AckAll or NAck.
This has been reflected correctly in 4.3.1:
"In that case, the NAS MUST set the Result field to AckAll (0x2) or  
Nack (0x1) according to its requirements."
But it has not yet been reflected in the multiple relevant subsections  
under section 6.
For example, section 6.2.3.2 says:
" It MUST then send a Multicast Admission Control message to the NAS  
indicating the deletion."
While this should depend on Result Code.
Also, section 6.3.2 says:
"If the flow was Grey-listed, the AN MUST then send a Multicast  
Admission Control message to the NAS indicating the deletion.  Thus  
the AN needs to retain the fact that
    the flow was Grey-listed for the life of the flow."
Again, I think responding would depend on the Result field. And I  
think the AN need not retain the fact that the flow was Grey-Listed.

* section 6.3.3:
it says:
"If either or both conditional access capabilities are combined with  
the delegated bandwidth capability, the AN always does admission
    control. "
I think this text is not correct and needs to be updated to reflect  
the White-List-CAC TLV and the MRepCtl-CAC TLV

There is also a bunch of editos I will share off-line with co-authors  
for next rev.

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 28 Oct 2009 16:51:37 +0100

One additional comment:

In section 6.2.4.2 (Delegated Bandwidth), I think we need to add a  
statement along the lines of "The NAS MAY at any time change the  
allocated bandwidth using …"

Francois

that the NAS

On 28 Oct 2009, at 16:43, Francois Le Faucheur wrote:

> Tom and all,
>
>> Francois had a hand in getting the main ideas into shape, but due  
>> to circumstances on my side he didn't have a chance to read and  
>> approve the final version of the draft.
>
> I reviewed the final text of section 6. In general, it is in line  
> with the discussions & conclusions Tom and I had.
>
> Below are a the most important comments that I'd like to make sure  
> we agree on:
>
> * 6.2.1. The case where CAC is done on NAS is clearly implied but  
> Provisioning message sent to the AN.  It MUST also include a  
> Bandwidth-Allocation TLV in a Port Management message for each  
> access line.
> "
> BY:
> the AN for NAS-initiated replication.  To do this, it MUST include  
> the MRepCtl-CAC TLV in a Provisioning message sent to the AN and it  
> MUST include a Bandwidth-Allocation TLV in a Port Management message  
> for each access line.
> "
>
> "The NAS can enable admission control at the AN for Grey-listed  
> flows. To do this, it MUST include the MRepCtl-CAC TLV in a  
> Provisioning message sent to the AN.  It MUST also provide a  
> Bandwidth-Allocation TLV in a Port Management message for each  
> access line.
> "
> BY:
> Alternatively, the NAS MAY enable admission control at the AN for  
> Grey-listed flows. To do this, it MUST include the MRepCtl-CAC TLV  
> in a Provisioning message sent to the AN and MUST also provide a  
> Bandwidth-Allocation TLV in a Port Management message for each  
> access line.
> "
>
>
> * Result Codes
> behavior. I don't feel strongly about that, but want to point out  
> this is a departure from what was agreed before and I am requesting  
> WG opinions on that.
>
>
> This comment assumes that the WG agrees that Results AckAll & NAck  
> is the right approach for some commands like Multicast Replication  
> Control.
> But it has not yet been reflected in the multiple relevant  
> subsections under section 6.
> There is also a bunch of editos I will share off-line with co- 
> authors for next rev.
>
> Francois

---

From: Tom Taylor <[email-masked]>
Date: Wed, 28 Oct 2009 15:26:23 -0400

My comments to Francois' proposals below.

Francois Le Faucheur wrote:
> Bandwidth-Allocation TLV in a Port Management message for each access line.
> "
> BY:
> "The NAS MAY perform admission control of the NAS-initiated replication. 
> NAS-initiated replication.  To do this, it MUST include the MRepCtl-CAC 
> TLV in a Provisioning message sent to the AN and it MUST include a 
> Bandwidth-Allocation TLV in a Port Management message for each access line.
> "
> 
> * 6.2.3.1. The case where CAC is done on NAS is clearly implied but not 
> message sent to the AN.  It MUST also provide a Bandwidth-Allocation TLV 
> in a Port Management message for each access line.
> "
> BY:
> Grey-listed flows. To do this, it MUST include the MRepCtl-CAC TLV in a 
> Provisioning message sent to the AN and MUST also provide a 
> Bandwidth-Allocation TLV in a Port Management message for each access line.
> "
> 
[PTT] OK with all above. You brought up the point privately that we could now 
drop the R flag from the Multicast Replication Control message. I agree with you 
-- we now have explicit controls at AN-level and don't need a control per flow too.
> instead of Ignore (as was done in previous versions) with a few commands 
> where AckAll & NAck seem ed to match teh desired response behavior. I 
> don't feel strongly about that, but want to point out this is a 
> departure from what was agreed before and I am requesting WG opinions on 
> that.
> 
> 
> "In that case, the NAS MUST set the Result field to AckAll (0x2) or Nack 
> (0x1) according to its requirements."
> Admission Control message to the NAS indicating the deletion.  Thus the 
> AN needs to retain the fact that
> Again, I think responding would depend on the Result field. And I think 
> the AN need not retain the fact that the flow was Grey-Listed.
> 
[PTT] I think you have the order wrong here. The Multicast Replication Control 
message is a response to the Multicast Admission Control message, not the other 
way around.
> 
> * section 6.3.3:
> it says:
> "If either or both conditional access capabilities are combined with the 
> delegated bandwidth capability, the AN always does admission
>    control. "
> I think this text is not correct and needs to be updated to reflect the 
> White-List-CAC TLV and the MRepCtl-CAC TLV
> 
[PTT] OK. I guess I saw the possibility that the NAS ended up choosing to do 
admission control for everything, in which case why bother to enable bandwidth 
delegation? But that isn't really a protocol issue.

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 29 Oct 2009 12:59:01 +0100

On 28 Oct 2009, at 20:26, Tom Taylor wrote:

>> MUST include a Bandwidth-Allocation TLV in a Port Management  
>> message for each access line.
>> "
> [PTT] OK with all above.

Ack.

> You brought up the point privately that we could now drop the R flag  
> from the Multicast Replication Control message. I agree with you --  
> we now have explicit controls at AN-level and don't need a control  
> per flow too.

Right. That should simplify operations quite a bit.

>> * Result Codes
>> On Tom's proposal, -01 reverted to using Result values AckAll &  
>> NAck instead of Ignore (as was done in previous versions) with a  
>> few commands where AckAll & NAck seem ed to match teh desired  
>> response behavior. I don't feel strongly about that, but want to  
>> point out this is a departure from what was agreed before and I am  
>> requesting WG opinions on that.
>> " It MUST then send a Multicast Admission Control message to the  
>> NAS indicating the deletion."
> [PTT] I think you have the order wrong here. The Multicast  
> Replication Control message is a response to the Multicast Admission  
> Control message, not the other way around.

My mistake. I got confused by the phrase "the AN receives a leave".  
This means that the AN receives an IGMP leave, and I thought it meant  
the AN receives a Multicast Replication Control message with a delete  
(as per NAS-initiated which is not applicable to these sections).  
Anyways, ignore my comment.

Regarding: "Thus the AN needs to retain the fact that the flow was  
Grey-listed for the life of the flow."
While a given AN implementation may "retain the fact", I think an AN  
implementation could potentially decide to re-subjects the "leave" to  
the White/Grey-List matching (and then it does not need to "retain the  
fact"). No? I am not arguing it is a better approach, just that we may  
not want to be overly prescriptive.
So perhaps we should change that sentence into something like :
""To that end the AN may retain the fact that the flow was Grey-listed  
for the life of the flow. Alternatively, it may subject the "leave"  
requests to Grey/White list matching".

>> * section 6.3.3:
>> it says:
>> "If either or both conditional access capabilities are combined  
>> with the delegated bandwidth capability, the AN always does admission
>>   control. "
> [PTT] OK. I guess I saw the possibility that the NAS ended up  
> choosing to do admission control for everything,

That is one scenario.

> in which case why bother to enable bandwidth delegation?

True.

> But that isn't really a protocol issue.

And there are other scenarios we want to allow. In particular, where  
the NAS decides to do admission control for Grey (and unicast) and  
requests the AN to do admission control for white, and bandwidth  
delegation is used to coordinate bandwidth between AN/White and NAS/ 
Grey&unicast.

So I would propose that for "White/Black + Grey + Bandwidth- 
Delegation" the distribution/control of admission control works the  
same as when we have "White/Black + Grey" (only the AN and NAS can now  
dynamically share bandwidth if/when appropriate).

Does that work for you (and all)?

Francois