[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
Hello Sven,
>
> <Sven> Ok, I suggest following wording:
>
> " 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. The
> decision must be taken irrespective of whether or not a corresponding
> Admission Request was issued by the AN earlier on."
>
> With this new requirement in place, I suggest to drop the
> following existing requirement because it also covered by the one
> above:
>
> " o Upon receiving an Admission Response from the NAS with a
> revocation of a previous admission decision, the AN must stop
> replication of the corresponding multicast flow to the corresponding
> Access Port."
> </Sven>
Agreed.
>
> * 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"
>
> <Sven> Ok. I suggest to reword to "containing conditional access
> and/or
> admission control information"</Sven>
Agreed.
>
> * 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."
>
> <Sven> I recall that this has been discussed before. I'm not in
> favor of
> adding this requirement, because of the timeout mechanism: too short
> timeouts make this a chatty solution (at which point one might as well
> query the NAS each time) - too long timeouts may result in rejecting
> requests even though bandwidth is available. </Sven>
I am happy to leave the choice of the actual mechanism to the
protocol design team (ie timeout or something else). But as far as
the requirements document is concerned, it seems useful to point out
that ANCP needs to support a mechanism to "release resources" when
those are no longer used by any flow of the pre-admitted set. Can we
try include a requirement to that effect and that leaves the actual
mechanism to the protocol design team?
Maybe something like:
" o after receiving ANCP messages from the NAS containing
admission control information for a set of multicast flows, the AN
should support using ANCP to notify the NAS when the admission for
this multicast flows set in no longer needed (e.g. there is no longer
any multicast flows from that set joined). This allows corresponding
bandwidth to be released on NAS."
>
> *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"
>
> <Sven> Ok, with the same rewording "conditional access and/or
> admission
> control information" </Sven>
Agreed
>
> * 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.
> "
>
> <Sven> I'm ok with this, but would change "may" to "should". </Sven>
OK
>
> *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.
> "
Sorry, I quoted the wrong requirement above (cut-and-paste error).
What I meant is :
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 NAS must support using ANCP to configure the Access Node with
the "maximum number of multicast streams" allowed to be received
concurrently per Access Port.
"
>
> <Sven> Perhaps this needs to be changed to:
>
> " o The ANCP MUST allow the NAS, when replying to an AN
> request, to convey information on multiple multicast flows sharing the
> same conditional access and/or admission control rules. This allows
> the
> AN to take autonomous decisions for these flows later on."
>
> That would make it in line with the AN and NAS requirements.
>
> </Sven>
>
I didn't actually have any problem with current wording for that
requirement. Either way is fine for me.
>
> 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.
>
> <Sven> I will change "IGMP joins" to "multicast joins" </Sven>
Agreed
Thanks
Francois
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp