[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] FW: New Version Notificationfordraft-ietf-pcn-architecture-06
Hi
I don't have a wish to delay the PCN architecture work more than necessary either.
I guess the way forward as described by Ruediger is reasonable i.e a description of the simple case and just a mention of the more complex cases in the architecture draft. On the other hand it may be sufficient to just mention aggregated reservation in general and rely on a future other document that covers this.
/Ingemar
> -----Original Message-----
> From: Geib, Ruediger [mailto:Ruediger.Geib at t-systems.com]
> Sent: den 16 september 2008 08:58
> To: Ingemar Johansson S
> Cc: pcn at ietf.org
> Subject: RE: [PCN] FW: New Version
> Notificationfordraft-ietf-pcn-architecture-06
>
> Ingemar,
>
> you bring up a fair question.
>
> I think that issues like how an aggregated RSVP reservation
> reacts on pre-congestion is out of scope for PCN.
>
> However a remark that PCN also works (or doesn't work??) with
> aggregated RSVP should be added. A fast take of me would be,
> that if there's just one level of aggregation and the
> aggregating/deaggregating nodes are the PCN ingress/egress
> nodes, then an interworking may be straightforward. But if
> there are more levels of aggregation or if PCN ingress/egress
> and RSVP aggregation/deaggregation are not the same nodes, it
> may become more troublesome. Especially, as the aggregated
> RSVP signaling doesn't have to follow the same path as the
> per flow RSVP signaling in the case of ECMP (that's an issue
> if the RSVP deagreggation node is outside of the PCN domain).
>
> I'd suggest to recommend operation of the simple case
> mentioned above in the current architecture.
>
> I'm not objecting on a bit more of discussion of the topic in
> the architecture, but that will delay the architecture
> document. I'm also open for a separate document describing
> aggregated RSVP(/NSIS?) and possibly the topic interworking
> of PCN with signaling as a whole. That would allow to
> finalise the architecture now.
>
> Regards,
>
> Ruediger
>
>
> -----Original Message-----
> From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On
> Behalf Of Ingemar Johansson S
> Sent: Monday, September 15, 2008 8:18 AM
> To: philip.eardley at bt.com; pcn at ietf.org
> Subject: Re: [PCN] FW: New Version
> Notificationfordraft-ietf-pcn-architecture-06
>
> Hi
>
> I have read through the draft and have one commment regarding
> RSVP aggregation which I believe is not commented in the
> draft (could be that I read badly though).
>
> I don't know if RSVP aggregation is a applicable for PCN and
> also I don't know how widely used it is (or will be).
>
> As I can see it from RFC3175. It should in theory be possible
> to use RSVP aggregation with PCN. In this case a PCN ingress
> domain will admit an aggregate of flows (which may increase
> and degrease over time as individual micro-flows are setup
> and torn down).
>
> Admission control in PCN should be relative straight-forward
> (atleast as seen from the power-point engineers viewpoint :-)
> as one could increase the "size" of the aggregates little by little.
> Termination may be more tricky though.. RFC4495 describes
> bandwidth reduction for RSVP aggregates, something that may
> work, but my question is if is fast enough ?.
> In order for it to work the reduction "requests" must be
> signaled back to the RSVP aggregation points which then can
> determine which microflows to terminate. Also it is possible
> that there is more than one level of aggregation.
> Given the possible cases where termination may be necessary
> (link-failures et.c) the only, fast enough solution may be to
> tear down the entire aggregate, something that may well be
> too brute-force.
>
> Is this a potential problem or yet another exotic corner case ?
>
> /Ingemar
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead"
> EAB/TVP - Multimedia Technologies
> Ericsson Research Ericsson AB
> Box 920 S-971 28 Luleå, Sweden
> Tel: +46 (0)8 4043042
> ECN: 850-43042
> ECC: 850-43074
> Mobile: +46 (0)730 783289
> *******************************************
>
>
> > -----Original Message-----
> > From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On
> Behalf Of
> > philip.eardley at bt.com
> > Sent: den 10 september 2008 21:32
> > To: pcn at ietf.org
> > Subject: [PCN] FW: New Version Notification
> > fordraft-ietf-pcn-architecture-06
> >
> > I've (hopefully) put in all the WG Last Call comments - thanks very
> > much to everyone who commented!
> >
> http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-06.txt
> >
> > Best wishes
> > phil
> >
> > ps The only issue I know about is that at some point the
> references to
> > I-Ds have to be referred to as "work in progress" rather
> than by the
> > ID name. hopefully this isn't too urgent and can wait until
> after the
> > next stage of the ietf review process.
> >
> > -----Original Message-----
> > From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org]
> > Sent: 10 September 2008 20:25
> > To: Eardley,PL,Philip,CXR9 R
> > Subject: New Version Notification for draft-ietf-pcn-architecture-06
> >
> >
> > A new version of I-D, draft-ietf-pcn-architecture-06.txt has been
> > successfuly submitted by Philip Eardley and posted to the IETF
> > repository.
> >
> > Filename: draft-ietf-pcn-architecture
> > Revision: 06
> > Title: Pre-Congestion Notification (PCN) Architecture
> > Creation_date: 2008-09-10
> > WG ID: pcn
> > Number_of_pages: 56
> >
> > Abstract:
> > This document describes a general architecture for flow
> admission and
> > termination based on pre-congestion information in order to protect
> > the quality of service of established inelastic flows
> within a single
> > DiffServ domain.Status
> >
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> > _______________________________________________
> > PCN mailing list
> > PCN at ietf.org
> > https://www.ietf.org/mailman/listinfo/pcn
> >
> _______________________________________________
> PCN mailing list
> PCN at ietf.org
> https://www.ietf.org/mailman/listinfo/pcn
>
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn