[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
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
>-----Original Message-----
>From: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org]On Behalf Of
>Stefaan DE CNODDER
>Sent: Monday, March 10, 2008 1:19 PM
>To: Wojciech Dec (wdec)
>Cc: OOGHE Sven; ancp at ietf.org
>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
>
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp