On 28 Oct 2009, at 20:26, Tom Taylor wrote:
My comments to Francois' proposals below. 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 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."[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.
[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.* Result CodesOn 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 thatthe 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.
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".
[PTT] OK. I guess I saw the possibility that the NAS ended up choosing to do admission control for everything,* section 6.3.3: it says:"If either or both conditional access capabilities are combined with the delegated bandwidth capability, the AN always does admissioncontrol. "I think this text is not correct and needs to be updated to reflect the White-List-CAC TLV and the MRepCtl-CAC TLV
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
There is also a bunch of editos I will share off-line with co- authors for next rev.Francois