[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
Hi Sven,
during Vancouver meeting we discussed about adding in the framework draft a new use case describing the Reporting capability; during the meeting no particular concerns or objections on the reporting functionality itself were raised, the only comment I received was related to one of the possible reporting method proposed ("AN global Report-Query")
My understanding from the meeting was that the proposed use case had been accepted in principle by the working group together with the "Port Report-Query" and "Multicast Flow Report-Query" proposed methods. Looking at the latest version of the framework draft I saw that the reporting capability has not been added thus I was wondering if you see any problem in inserting this use case in the framework draft.
Please let me know.
Thanks and best regards
Roberta
-----Original Message-----
From: ancp-bounces at ietf.org on behalf of Francois Le Faucheur IMAP
Sent: Wed 3/5/2008 10:30 AM
To: OOGHE Sven; ancp at ietf.org
Subject: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
Hello,
Please find below a few comments/suggestions on framework-05.
Francois
* under section 3.4.2: first bullet.
The following text has been added:
"The NAS may locally maintain available "video"
bandwidth on the Access Loop, and perform video bandwidth
accounting for the Access Loop. Upon receiving an Admission
Request from the AN, the NAS can check available "video"
bandwidth
before admitting or denying the multicast flow. In the process,
the NAS may communicate with the Policy Server. For unicast
video
services such as Video on Demand (VoD), the Policy Server may
also
query the NAS, so that it can perform admission control for the
unicast flow, and update the available video bandwidth maintained
by the NAS.
"
Could we make this slightly more generic and replace the last
sentence with something like:
"For unicast video services such as Video on Demand (VoD), the NAS
may also be queried (by a Policy Server or via on-path CAC
signaling), so that it can perform admission control for the unicast
flow, and update the available video bandwidth maintained by the NAS."
* section 3.4.2: 2nd bullet.
Similarly could we replace:
"For unicast video services the policy server may query the NAS to
perform admission control for the unicast flow, and update the
available video bandwidth maintained by the NAS."
by
"For unicast video services the NAS may be queried (by a policy
server or via on-path CAC signaling) to perform admission control for
the unicast flow, and update the available video bandwidth maintained
by the NAS."
* section 4.7.6
The last requirement in the section is intended to reflect the
"Spontaneous Admission Response" functionality described in section
3.4.4.
As agreed, one scenario has been added to section 3.4.4 (ie where the
NAS is made aware of Join/Leave by other means than ANCP), and this
scenario needs to be reflected in section 4.7.6. I'd suggest adding
something like:
" o Upon receiving an Admission Response from the NAS indicating
that replication of a multicast flow is to start or stop on a given
access port of the AN, the AN must enforce this decision whether a
corresponding Admission Request was issued earlier by the AN or not.
"
* section 4.7.6:
replace:
"the AN should support receiving ANCP messages from the NAS
containing conditional access information of multiple multicast flows"
by
"the AN should support receiving ANCP messages from the NAS
containing conditional/admission access information of multiple
multicast flows"
* section 4.7.6
There is one requirement stating that
"the AN should support receiving ANCP messages from the NAS
containing conditional access information of multiple multicast flows."
The details of such mechanism is largely left to the protocol design
team, which is fine.
But it may be useful to identify one additional associated
requirement on AN, allowing AN to tell NAS that there is no longer
any multicast flows joined (within the admitted set of flows) so the
corresponding bandwidth can be freed up (where CAC is performed).
This could read :
" o after receiving ANCP messages from the NAS containing
conditional access information of a set of multicast flows, the AN
should support using ANCP to notify the NAS when there is no longer
any multicast flows from that set joined for a configurable time-out
period."
*section 4.8.6:
replace:
"the NAS should support sending an Admission Response message
containing conditional access information of multiple multicast flows"
by
"the NAS should support sending an Admission Response message
containing conditional/admission access information of multiple
multicast flows"
* section 4.8.6:
there needs to be a requirement here also for spontaneous admission
response. I would propose:
" o the NAS may support using ANCP to indicate to the AN that
replication of a multicast flow is to start or stop on a given access
port of the AN, without having received a corresponding Admission
Request earlier from the AN.
"
*section 4.8.6
I believe the WG agreed that the following text needs to be confirmed
on the list before it could stay in framework doc.
"
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.
"
editorial suggestions:
================
* Section 3.4:
Current text:
"The NAS can perform conditional
access and multicast admission control on IGMP joins, and create
replication state in the AN if the flow is admitted by the NAS."
Change:
replace "IGMP joins" by "joins"
Justification:
Joins/leaves may be communicated via IGMP or via some other means.
* section 3.4.2.2
replace:
"Otherwise, the Access Node would have to query the NAS for Multicast
Admission Control"
by:
"Otherwise, the Access Node would have to query the NAS for Multicast
Admission Control (as per Grey List behavior)"
Typos:
=====
* section 3.4.2:
s/as well as for other a set of multicast flows/as well as for a set
of multicast flows/
* in a few places: replace "lateron" by "later on"
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp
--------------------------------------------------------------------
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 webmaster at telecomitalia.it.
Thank you
www.telecomitalia.it
--------------------------------------------------------------------
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp