[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
Hi Stefaan,
Inline...
> -----Original Message-----
> From: Stefaan DE CNODDER
> [mailto:stefaan.de_cnodder at alcatel-lucent.be]
> Sent: 10 March 2008 13:49
> To: Wojciech Dec (wdec)
> Cc: OOGHE Sven; Maglione Roberta; Francois Le Faucheur
> (flefauch); ancp at ietf.org; BOCCI Matthew
> Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
>
>
>
> Hi Woj,
>
> Wojciech Dec (wdec) wrote:
>
> > 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.
>
> 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 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.
>
> >
> > 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.
>
> 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.
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.
>
> regards,
> Stefaan
>
>
>
> >
> > Regards,
> > Woj.
> >
> >
> >>-----Original Message-----
> >>From: Stefaan DE CNODDER
> >>[mailto:stefaan.de_cnodder at alcatel-lucent.be]
> >>Sent: 10 March 2008 13:19
> >>To: Wojciech Dec (wdec)
> >>Cc: OOGHE Sven; Maglione Roberta; Francois Le Faucheur (flefauch);
> >>ancp at ietf.org; BOCCI Matthew
> >>Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
> >>
> >>
> >>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
> >>
> >>
> >>Wojciech Dec (wdec) wrote:
> >>
> >>>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.
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: ancp-bounces at ietf.org
> [mailto:ancp-bounces at ietf.org] On Behalf
> >>>>Of OOGHE Sven
> >>>>Sent: 07 March 2008 05:18
> >>>>To: Maglione Roberta; Francois Le Faucheur (flefauch);
> >>>>ancp at ietf.org; 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.
> >>>>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.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
> >>>>
> >>>>-----Original Message-----
> >>>>From: Maglione Roberta [mailto:roberta.maglione at telecomitalia.it]
> >>>>Sent: donderdag 6 maart 2008 23:39
> >>>>To: Francois Le Faucheur IMAP; OOGHE Sven; ancp at ietf.org
> >>>>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: 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
> >>>>
> >>>
> >>>_______________________________________________
> >>>ANCP mailing list
> >>>ANCP at ietf.org
> >>>https://www.ietf.org/mailman/listinfo/ancp
> >>
> >
>
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp