Subject: [ANCP] Comments on draft-ietf-ancp-framework-05.txt

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 5 Mar 2008 10:30:29 +0100

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: "Maglione Roberta" <[email-masked]>
Date: Thu, 6 Mar 2008 23:39:05 +0100

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: [email-masked] on behalf of Francois Le Faucheur IMAP
Sent: Wed 3/5/2008 10:30 AM
To: OOGHE Sven; [email-masked]
Subject: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
 
Hello,

Francois

* section 4.7.6

* section 4.7.6:
replace:

* section 4.7.6

*section 4.8.6:
replace:

* section 4.8.6:

*section 4.8.6

editorial suggestions:
================
* Section 3.4:
Current text:

* section 3.4.2.2
replace:

Typos:
=====
* section 3.4.2:

--------------------------------------------------------------------

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 [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: "OOGHE Sven" <[email-masked]>
Date: Fri, 7 Mar 2008 11:17:39 +0100

Hi Roberta,

Thanks for bringing this up. The latest version of the framework draft
tries to capture all agreements reached since the Vancouver meeting. In
doing so, I had to rely on the meeting minutes posted on
http://www.ietf.org/proceedings/07dec/minutes/ancp.txt. In those
minutes, I couldn't find clear statements on this topic. Also in the
discussions on the mailing list, I haven't seen a clear conclusion.
That's why I wasn't able to describe reporting mechanisms in the update.

Related to this, the chairs indicated in
http://www.ietf.org/mail-archive/web/ancp/current/msg00479.html that the
scope of the framework and protocol work would be somewhat constrained
in order to avoid further delay. I considered that the reporting
capabilities would be part of the WG decision to re-charter or add new
milestones for protocol extensions.

So perhaps at this point I would like to ask the chairs for guidance on
this topic.

Regards,
Sven

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]] 
Sent: donderdag 6 maart 2008 23:39
To: Francois Le Faucheur IMAP; OOGHE Sven; [email-masked]
Subject: 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: [email-masked] on behalf of Francois Le Faucheur IMAP
Sent: Wed 3/5/2008 10:30 AM
To: OOGHE Sven; [email-masked]
Subject: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
 
Hello,

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

* 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:

*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:

* section 3.4.2.2
replace:

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
[email-masked]
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
[email-masked].

        Thank you

                                        www.telecomitalia.it

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 10 Mar 2008 08:05:43 -0400

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.

> <Sven> Ok. I suggest to reword to "containing conditional access  
> and/or
> admission control information"</Sven>

Agreed.

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

> containing
> containing
> <Sven> Ok, with the same rewording "conditional access and/or  
> admission
> control information" </Sven>

Agreed

> <Sven> I'm ok with this, but would change "may" to "should". </Sven>

OK

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

> <Sven> I will change "IGMP joins" to "multicast joins" </Sven>

Agreed

Thanks

Francois

---

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 10 Mar 2008 09:57:52 +0100

Hello Francois,

Thanks for reviewing. See feedback inline.

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: woensdag 5 maart 2008 10:30
To: OOGHE Sven; [email-masked]
Cc: Francois Le Faucheur IMAP
Subject: Comments on draft-ietf-ancp-framework-05.txt

Hello,

Francois

<Sven> Agreed. I will made the change </Sven>

<Sven> Ok. </Sven>

* section 4.7.6

indicating that replication of a multicast flow is to start or stop on a

 	With this new requirement in place, I suggest to drop the
following existing requirement because it also covered by the one above:

* section 4.7.6:
replace:

<Sven> Ok. I suggest to reword to "containing conditional access and/or
admission control information"</Sven>

* section 4.7.6

<Sven> I recall that this has been discussed before. I'm not in favor of

*section 4.8.6:
replace:

<Sven> Ok, with the same rewording "conditional access and/or admission
control information" </Sven>

* section 4.8.6:

*section 4.8.6

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

</Sven>

editorial suggestions:
================
* Section 3.4:
Current text:

* section 3.4.2.2
replace:

<Sven> Ok. </Sven>

Typos:
=====
* section 3.4.2:

<Sven> Ok. </Sven>

Regards,
Sven

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 10 Mar 2008 15:39:58 +0100

Hi Folks,

allow me to assume that we're talking about multicast reporting and not
accounting (previously the two got often confused), ie the report
conveys only a snapshot of the multicast state on the queried node's
target, without conveying the flow(s) byte or duration counters.

Now, I went back to check where the reporting items originated from and
found the following sources/references:
A. Reporting was listed/proposed way back at IETF 68
(http://www.ietf.org/proceedings/07mar/slides/ancp-4/sld7.htm)
B. It is listed as an ANCP open item regarding WT-147 (WT147 contains at
least two mcast reporting requirements)
C. Reporting was discussed in Vancouver under the ANCP Multicast Update
item, and a specific proposal was put forward to include relevant text.
D. Reporting was cited to be useful for graceful restart (minuted in
Vancouver, but this context was also in the graceful restart draft)

More specifically reporting was defined/proposed to be at 3 levels of
granularity:
1) Report per port
2) Report per flow (across AN)
3) Global AN multicast flow & port Report 

The Vancouver minutes contain no firm conclusion on any of the above,
but do indicate that the discussion was muddled up other tangential
topics to this one (lists, accounting, etc). It is my impression that
with the clarification that reporting is NOT accounting, NOR is it
anything to do with lists, the functionality is fairly straight forward
and has a fair bit of support.
 
Given the above, besides the facts that it appears fairly
uncontroversial, that the design team already made inroads into this,
and that it has been on the table for a good deal of time, I would say
that reporting is a fair topic to be addressed by the WG sooner rather
than later, and in the current framework document (a specific proposal
appears to exist, but likely needs some editorial work). 

Regards,
Woj.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of OOGHE Sven
> Sent: 07 March 2008 05:18
> To: Maglione Roberta; Francois Le Faucheur (flefauch); 
> [email-masked]; Wojciech Dec (wdec); BOCCI Matthew
> Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
> 
> Hi Roberta,
> 
> Thanks for bringing this up. The latest version of the 
> framework draft tries to capture all agreements reached since 
> the Vancouver meeting. In doing so, I had to rely on the 
> meeting minutes posted on 
> http://www.ietf.org/proceedings/07dec/minutes/ancp.txt. In 
> those minutes, I couldn't find clear statements on this 
> topic. Also in the discussions on the mailing list, I haven't 
> seen a clear conclusion.
> http://www.ietf.org/mail-archive/web/ancp/current/msg00479.htm
l that the scope of the framework and protocol work would be > somewhat
constrained in order to avoid further delay. I 
> considered that the reporting capabilities would be part of 
> the WG decision to re-charter or add new milestones for 
> protocol extensions.
> 
> So perhaps at this point I would like to ask the chairs for 
> guidance on this topic.
> 
> Regards,
> 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
> 
> 
> 
>        the NAS may communicate with the Policy Server.  For 
> unicast video
>        services such as Video on Demand (VoD), the Policy 
> Server may also
> "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."
> 
> "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 
> 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:
> 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:
> containing conditional/admission access information of 
> multiple multicast flows"
> 
> * section 4.7.6
> The details of such mechanism is largely left to the protocol 
> design team, which is fine.
> 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 :
> 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:
> 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:
> 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.
> "
> "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/
> 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

---

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 10 Mar 2008 16:15:25 +0100

Hi Francois, 

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

<Sven> Sounds like a good way forward. How about rewording your proposal
to the following:

"   o  The AN should support using ANCP to notify the NAS when resources
for a multicast flow are no longer in use (e.g. the AN is no longer
replicating any multicast flows from a set of multicast flows sharing
the same admission control rules). This allows corresponding bandwidth
to be released on NAS."

</Sven>

<Sven> I posted this request on the exploder in November last year, see
http://www.ietf.org/mail-archive/web/ancp/current/msg00409.html. There
was one reply indicating that this would be ok
(http://www.ietf.org/mail-archive/web/ancp/current/msg00410.html), and I
have not seen anybody oppose. I therefore kept it in.

> the AN to take autonomous decisions for these flows later on."
>

<Sven> Ok. I will use the new wording to increase consistency with the
other requirements. </Sven>

Regards,
Sven

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Mon, 10 Mar 2008 18:18:49 +0100

Woj,

According to me this reporting all is a bit of controversial.  People 
say that it is useful for graceful restart while there is no draft about 
graceful restart.  I remember a very old draft on it, on which I posted 
comments but never answered.  Since there is no document about GR, this 
means that it is also hard to determine if with this reporting function 
covers all cases for gracefull restart.  I also think it is also not 
that straitforward to define the protocol because a lot of data has to 
be transferred from AN to NAS and that data does not fit in a single 
packet.  So therefore, I would prefer to do this rather later than 
sooner.  Why is there such a hurry for it?

regards,
Stefaan

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Mon, 10 Mar 2008 18:23:30 +0100

Hi Francois,

Why would on-path CAC signaling query the NAS?  Since it is on-path, it 
is already on the NAS, so it will never query the NAS?

regards,
Stefaan

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 10 Mar 2008 18:37:17 +0100

Hi Stefaan,

the controversies I have been able to find concerned the distinction
between accounting and reporting, which has now been clarified. However,
I would agree that the application of graceful restart is wider than
just mcast flow reporting, and thus can be considered for a follow on
phase.
Can you point me to the comments/thread that wasn't answered?

Regarding the issues of not fitting into a single packet, and/or a lot
of data, these appear to be already addressed with the length and
sub-message number fields in the base GSMP header, besides the use of
TCP. 

Regards,
Woj.

> From: Stefaan DE CNODDER 
> [mailto:[email-masked]] 
> Sent: 10 March 2008 13:19
> To: Wojciech Dec (wdec)
> Cc: OOGHE Sven; Maglione Roberta; Francois Le Faucheur 
> (flefauch); [email-masked]; BOCCI Matthew
> According to me this reporting all is a bit of controversial. 
>  People say that it is useful for graceful restart while 
> there is no draft about graceful restart.  I remember a very 
> old draft on it, on which I posted comments but never 
> answered.  Since there is no document about GR, this means 
> that it is also hard to determine if with this reporting 
> function covers all cases for gracefull restart.  I also 
> think it is also not that straitforward to define the 
> protocol because a lot of data has to be transferred from AN 
> to NAS and that data does not fit in a single packet.  So 
> therefore, I would prefer to do this rather later than

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Mon, 10 Mar 2008 18:49:21 +0100

Hi Woj,

> just mcast flow reporting, and thus can be considered for a follow on

good

> Can you point me to the comments/thread that wasn't answered?

I do not know if it is really useful to suddenly start discussing a 
non-WG draft expired long time ago.  Anyhow, if the authors would want 
to plan a new draft, here were the comments:

http://www.ietf.org/mail-archive/web/ancp/current/msg00028.html
http://www.ietf.org/mail-archive/web/ancp/current/msg00026.html

I am not sure that replying to these old emails are useful because I 
must say that I do not remember anymore all the details.  Anyhow usefull 
information for an updated draft.

> sub-message number fields in the base GSMP header, besides the use of

The current ANCP protocol says: "An ANCP implementation SHOULD set the I 
and subMessage fields to 1 to signify no fragmentation."   Clearly, ANCP 
is not designed for such fragmentation.  Now you can say: "Ok lets add 
the GSMP fragmentation to ANCP as well", but I do not think it is that 
obvious because in past discussions it was clear that sometimes just new 
fields are defined for existing GSMP fields (length fields, Transaction 
ID), and then we also have to think what if there is a lot of data to 
sent, the TCP session may reach its maximum window and other ANCP 
messages might get delayed.

regards,
Stefaan

>>>allow me to assume that we're talking about multicast 
>>
>>reporting and not
>>
>>>Now, I went back to check where the reporting items 
>>
>>originated from and
>>
>>>B. It is listed as an ANCP open item regarding WT-147 
>>
>>(WT147 contains at
>>
>>>C. Reporting was discussed in Vancouver under the ANCP 
>>
>>Multicast Update
>>
>>>item, and a specific proposal was put forward to include 
>>
>>relevant text.
>>
>>>More specifically reporting was defined/proposed to be at 3 
>>
>>levels of
>>
>>>granularity:
>>>1) Report per port
>>>The Vancouver minutes contain no firm conclusion on any of 
>>
>>the above,
>>
>>>topics to this one (lists, accounting, etc). It is my 
>>
>>impression that
>>
>>>anything to do with lists, the functionality is fairly 
>>
>>straight forward
>>
>>>uncontroversial, that the design team already made inroads 
>>
>>into this,
>>
>>>and that it has been on the table for a good deal of time, 
>>
>>I would say
>>
>>>that reporting is a fair topic to be addressed by the WG 
>>
>>sooner rather
>>
>>>than later, and in the current framework document (a 
>>
>>specific proposal
>>
>>>l that the scope of the framework and protocol work would 
>>
>>be > somewhat
>>
>>>>      query the NAS, so that it can perform admission 
>>
>>control for the
>>
>>>>"   o  Upon receiving an Admission Response from the NAS 
>>
>>indicating  
>>
>>>>containing conditional access information of multiple 
>>
>>multicast flows"
>>
>>>>by
>>>>containing conditional access information of multiple 
>>
>>multicast flows"
>>
>>>>by
>>>>   o  The ANCP MUST allow the NAS, when replying to an AN 
>>
>>request, to
>>
>>>>      the same conditional access rules.  This allows the 
>>
>>AN to take
>>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 10 Mar 2008 13:55:31 -0400

> this

I think we need to make it clear upfront that we are talking about  
"resources for a set of multicast flow" and not "resources for a  
multicast flow".
How about:

    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 those resources
are no longer in use (e.g. the AN is no longer replicating any
multicast flows from that that set). This allows corresponding
bandwidth to be released on NAS."

Francois

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 10 Mar 2008 19:02:55 +0100

Hi Stefaan,

Inline... 

> Sent: 10 March 2008 13:49
> To: Wojciech Dec (wdec)
> > between accounting and reporting, which has now been clarified. 
> > However, I would agree that the application of graceful restart is 
> > wider than just mcast flow reporting, and thus can be 
> considered for a 
> > follow on phase.
> 
> good
> 
> I do not know if it is really useful to suddenly start 
> discussing a non-WG draft expired long time ago.  Anyhow, if 
> the authors would want to plan a new draft, here were the comments:
> 

I do not see mcast flow reporting mentioned in the above, but rather
issues regarding graceful restart.

> 
> I am not sure that replying to these old emails are useful 
> because I must say that I do not remember anymore all the 
> details.  Anyhow usefull information for an updated draft.
> 
> > 
> is not designed for such fragmentation.  Now you can say: "Ok 
> lets add the GSMP fragmentation to ANCP as well", but I do 
> not think it is that obvious because in past discussions it 
> was clear that sometimes just new fields are defined for 
> existing GSMP fields (length fields, Transaction ID), and 
> then we also have to think what if there is a lot of data to 
> sent, the TCP session may reach its maximum window and other 
> ANCP messages might get delayed.

There is a relatively simple fix to this, as you already indicate. We
cannot/will not solve TCP issues in ANCP, and it is a natural
consequence for us today reagirding this transport protocol. Alternative
transports can be considered for the future, but for the time being TCP
is the one we have and I see no reason why it cannot handle this usage
within its known limits. Coincidentally the bulk update mechanism that
is currently covered already runs into this TCP issue as well. As such,
I still beleive that flow reports are to be covered.

Regards,
Woj.

> >>Cc: OOGHE Sven; Maglione Roberta; Francois Le Faucheur (flefauch); 
> >>[email-masked]; BOCCI Matthew
> there is no 
> >>draft about graceful restart.  I remember a very old draft 
> on it, on 
> >>which I posted comments but never answered.  Since there is no 
> >>document about GR, this means that it is also hard to determine if 
> >>with this reporting function covers all cases for gracefull 
> restart.  
> >>I also think it is also not that straitforward to define 
> the protocol 
> >>because a lot of data has to be transferred from AN to NAS and that 
> >>data does not fit in a single packet.  So therefore, I 
> would prefer to 
> >>do this rather later than sooner.  Why is there such a hurry for it?
> >>
> >>regards,
> >>Stefaan
> >>
> >>
> >>>least two mcast reporting requirements) C. Reporting was 
> discussed in 
> >>>Vancouver under the ANCP
> >>
> >>Multicast Update
> >>
> >>>>From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> >>>>Of OOGHE Sven
> >>>>Thanks for bringing this up. The latest version of the framework 
> >>>>draft tries to capture all agreements reached since the Vancouver 
> >>>>meeting. In doing so, I had to rely on the meeting 
> minutes posted on 
> >>>>considered that the reporting capabilities would be part 
> of the WG 
> >>>>decision to re-charter or add new milestones for protocol 
> >>>>extensions.
> >>>>
> >>>>So perhaps at this point I would like to ask the chairs 
> for guidance 
> >>>>on this topic.
> >>>>
> >>>>Regards,
> >>>>Sven
> >>>>
> the framework 
> >>>>draft a new use case  describing the Reporting capability; during 
> >>>>the meeting no particular concerns or objections on the reporting 
> >>>>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
> >>>>
> >>>>
> >>>>
> Server may 
> >>>>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
> >>>>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:
> >>>>There is one requirement stating that "the AN should support 
> >>>>receiving ANCP messages from the NAS containing 
> conditional access 
> >>>>information of multiple multicast flows."
> >>>>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 :
> >>>>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
> >>>>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 [email-masked].
> >>>>
> >>>>       Thank you
> >>>>
> >>>>                                       www.telecomitalia.it
> >>>>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 10 Mar 2008 14:03:48 -0400

On 10 Mar 2008, at 13:23, Stefaan DE CNODDER wrote:

>
> Hi Francois,
>
> Why would on-path CAC signaling query the NAS?  Since it is on- 
> path, it is already on the NAS, so it will never query the NAS?

All I am saying is that, in the case of on-path signaling, the NAS is  
effectively queried by the on-path signaling itself.
I think we're in agreement.

Francois

>>        services such as Video on Demand (VoD), the Policy Server  
>> may  also
>> "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  
>> "For unicast video services the policy server may query the NAS  
>> to  perform admission control for the unicast flow, and update  
>> "Spontaneous Admission Response" functionality described in  
>> section  3.4.4.
>> 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:
>> 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  
>> flows) so the  corresponding bandwidth can be freed up (where CAC  
>> is performed).  This could read :
>> 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  
>> s/as well as for other a set of multicast flows/as well as for a  
>> set  of multicast flows/

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Mon, 10 Mar 2008 19:27:46 +0100

Woj,

replies in line...

Wojciech Dec (wdec) wrote:

>>>the controversies I have been able to find concerned the 
>>
>>distinction 
>>

My point is that GR was never discussed at the WG and therefore for the 
moment, no extensions have to be defined for GR for the moment.

>>>Regarding the issues of not fitting into a single packet, 
>>
>>and/or a lot 
>>
>>>sub-message number fields in the base GSMP header, besides 
>>
>>the use of 
>>
>>>TCP.
>>
> within its known limits.

I never questioned the use of TCP, for me, TCP is just fine.

  Coincidentally the bulk update mechanism that
> is currently covered already runs into this TCP issue as well.

I disagree on this one.  Obviously, TCP might always be a bottleneck 
(which we simply have to accept) but with the active-flow-all it might 
become a lot worse.  Whether ANCP messages are put in a bulk message or 
not, does not change much to the TCP behaviour.  But if you add a lot of 
packets to be transferred such as with the active-flow-all, then the 
data generated by the active-flow-all might take the whole TCP window, 
and the other messages are delayed.  For GR, this delay is not that 
important because a node is recovering from a reset but again: we do not 
have to define protocol extensions for GR at this moment.

regards,
Stefaan

  As such,
>>>>>conveys only a snapshot of the multicast state on the 
>>
>>queried node's 
>>
>>>>>D. Reporting was cited to be useful for graceful restart 
>>
>>(minuted in 
>>
>>>>>but do indicate that the discussion was muddled up other 
>>
>>tangential 
>>
>>>>>>minutes, I couldn't find clear statements on this topic. 
>>
>>Also in the 
>>
>>>>>>discussions on the mailing list, I haven't seen a clear 
>>
>>conclusion.
>>
>>>>>>related to one of the possible reporting method proposed 
>>
>>("AN global
>>
>>>>>>     the NAS may communicate with the Policy Server.  
>>
>>For unicast 
>>
>>>>>>video
>>>>>>"For unicast video services such as Video on Demand 
>>
>>(VoD), the NAS 
>>
>>>>>>signaling), so that it can perform admission control for 
>>
>>the unicast 
>>
>>>>>>"For unicast video services the policy server may query 
>>
>>the NAS to 
>>
>>>>>>"Spontaneous Admission Response" functionality described 
>>
>>in section 
>>
>>>>>>3.4.4.
>>>>>>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 details of such mechanism is largely left to the 
>>
>>protocol design 
>>
>>>>>>team, which is fine.
>>>>>>requirement on AN, allowing AN to tell NAS that there is 
>>
>>no longer 
>>
>>>>>>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:
>>>>>>  access and multicast admission control on IGMP joins, 
>>
>>and create
>>
>>>>>>  replication state in the AN if the flow is admitted by 
>>
>>the NAS."
>>
>>>>>>Change:
>>>>>>s/as well as for other a set of multicast flows/as well 
>>
>>as for a set 
>>
>>>>>>of multicast flows/
>>>>>>----------------------------------------------------------
>>
>>----------
>>
>>>>>>CONFIDENTIALITY NOTICE
>>>>>>
>>>>>>This message and its attachments are addressed solely to 
>>
>>the persons 
>>
>>>>>>----------------------------------------------------------
>>
>>----------
>>
>>>>>>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 10 Mar 2008 19:57:13 +0100

Stefaan,

inline... 

> Sent: 10 March 2008 14:28
> To: Wojciech Dec (wdec)
> My point is that GR was never discussed at the WG and 
> therefore for the moment, no extensions have to be defined 
> for GR for the moment.
> 

We're in agreement on this one; GR is for a futher stage, but it is
largely decoupled from reporting, which thus deserves to be covered.

> because I 
> >>must say that I do not remember anymore all the details.  Anyhow 
> >>usefull information for an updated draft.
> >>
> >>
> >>The current ANCP protocol says: "An ANCP implementation 
> SHOULD set the 
> >>I
> >>obvious because in past discussions it was clear that 
> sometimes just 
> >>new fields are defined for existing GSMP fields (length fields, 
> >>Transaction ID), and then we also have to think what if 
> there is a lot 
> >>of data to sent, the TCP session may reach its maximum window and 
> >>other ANCP messages might get delayed.
> > 
> > 
> > consequence for us today reagirding this transport protocol. 
> > Alternative transports can be considered for the future, 
> but for the 
> > time being TCP is the one we have and I see no reason why it cannot 
> > handle this usage within its known limits.
> 
> I disagree on this one.  Obviously, TCP might always be a 
> bottleneck (which we simply have to accept) but with the 
> active-flow-all it might become a lot worse.  Whether ANCP 
> messages are put in a bulk message or not, does not change 
> much to the TCP behaviour.  But if you add a lot of packets 
> to be transferred such as with the active-flow-all, then the 
> data generated by the active-flow-all might take the whole 
> TCP window, and the other messages are delayed.  For GR, this 
> delay is not that important because a node is recovering from 
> a reset but again: we do not have to define protocol 
> extensions for GR at this moment.

The above is questionable as is all an artefact of TCP (the same problem
arises if you get a burst of Port-UPs, a long OAM ping response, etc,
etc). As such it is not as a show stopper for proceeding with the
reporting functionality. 

Regards,
Woj.

> framework 
> >>>>>>That's why I wasn't able to describe reporting 
> mechanisms in the 
> >>>>>>update.
> >>>>>>
> >>>>>>From: Maglione Roberta 
> [mailto:[email-masked]]
> >>>>>>flow, and update the available video bandwidth 
> maintained by the 
> >>>>>>NAS."
> >>>>>>

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Mon, 10 Mar 2008 15:37:26 -0400

Stefaan
  I don't see how we can get away without the reporting capability,
irrespective of graceful restart. As has been discussed before, when
replication function and control function are split between AN and NAS,
from a user's perspecitve, NAS + AN needs to be treated as a single
black-box. If both fucntions were performed on a single box (where the
control and forwarding is decoupled), it is hard to imagine that an
operator will not expect support to see replication state for flows (and
per-flow stats etc) from the hardware that hosts the control plane on
the box. The requirement and expectation doesn't change if these
functions are run on two different network elements. 

You mention below information not fitting in a single packet....

> it is also not that straitforward to define the protocol because a lot
of data has to be transferred from AN to NAS and that
> data does not fit in a single packet

Graceful restart for any dynamic protocol typically requires state
resynchronization between network elements. I don't believe it is
required that the state synchronization is achieved via a single
message. The GR draft does not impose or suggest such a requirement. It
actually suggests a new "END-OF-STATE" adjacency message to signal when
all the state has been replayed by the neighbor.

Regards
-Sanjay 

>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Stefaan DE CNODDER
>Sent: Monday, March 10, 2008 1:19 PM
>To: Wojciech Dec (wdec)
>Cc: OOGHE Sven; [email-masked]
>> l that the scope of the framework and protocol work would be 
>> somewhat
>>>multicast flows."

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 11 Mar 2008 16:58:23 +0100

Hi Francois,

I'm ok with the reworded requirement below.

Regards,
Sven

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: maandag 10 maart 2008 18:56
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; [email-masked]
Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt

> 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 
> <Sven> Sounds like a good way forward. How about rewording your 
> proposal to the following:
>

    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 those resources are no longer in use
(e.g. the AN is no longer replicating any multicast flows from that that
set). This allows corresponding bandwidth to be released on NAS."

Francois