Re: reminder: things todo in august and shortly thereafter

[Tricci So <tso@caspiannetworks.com>]

Hi WaiSum,

Thank you for your clarification.   I have two comments to your reply.

(1) I agree with you 100% that it is necessary to be able to differentiate and
prioritize the control traffic over the user traffic.  However, I don't believe
that we need to support pre-emption to achieve such need.  Simply by
differentiating  the control traffic from user traffic and applying preferential
treatment within the switch/router would be suffiicient.

(2) Regarding to my previous point#3, my real concern is not whether we can
provide crankback to re-select new route for the traffic.  My concern is
regarding to your statement that I quoted could allow  possible conflicting
preemption configuration within the network among different nodes which could
then introduce more rerouting instability.

Cheers,
Tricci


"Lai, Wai S (Waisum), ALSVC" wrote:

> Tricci,
>    Many thanks for your comments.  I agree with you totally that both the
> concept and requirements of preemption have not been treated very well in
> <draft-ietf-tewg-diff-te-reqts-01.txt>, even with my proposed addition of
> text for more clarification.  The questions you raised in points 1 and 2
> below pinpoint exactly the problem of using preemption and its associated
> complexity.
>    Jim in his response pointed out that bumping is a policy and
> implementation issue local to a node.  While this is true since
> interoperable protocol is not required in this aspect (and also currently
> not available), there is the issue of assuring end-to-end QoS as I raised
> towards the end of Section 2.5.2, particularly when different service
> providers can assign different class types, different classes, different
> priority treatment to the same service as perceived by an end user.  In view
> of this lack of interoperable standard, use of preemption among user traffic
> should be avoided as far as possible.  However, preemption does play a role
> for control traffic over user traffic.
>    Regarding your point 3, both EF and BE traffic are admitted by using the
> admission control/crankback procedure described in
> <draft-ash-mpls-diffserv-te-alternative-02.txt>.  (BTW, this procedure also
> applies to the scenarios described in Section 1 of the draft, along with
> restoration priority for the failure scenarios.)  After admission, as
> explained in my proposed text, EF and BE are accommodated via bandwidth
> sharing through the adaptivity of BE traffic.  This can be regarded as
> preemption at the packet level through queueing/scheduling mechanisms, but
> not connection-level preemption as described in
> <draft-ietf-tewg-diff-te-reqts-01.txt>.
>    I think your comments on <draft-ash-mpls-diffserv-te-alternative-02.txt>
> have already been covered by Jerry.
> Thanks, Wai Sum.
>
> -----Original Message-----
> From: Tricci So [mailto:tso@caspiannetworks.com]
> Sent: Wednesday, August 29, 2001 2:23 AM
> To: Lai, Wai S (Waisum), ALSVC
> Cc: 'te-wg@ops.ietf.org'
> Subject: Re: reminder: things todo in august and shortly thereafter
>
> Hi Waisum,
>
> Thank you for the drafts.  Since the deadline for the Diff-TE requirements
> is closer, I will
> first send you my comments on the two TE drafts.
>
> draft-ietf-tewg-diff-te-reqts-01.txt.
>
> The most unclear to me for this draft is the handling of the pre-emption.  I
> would very much
> appreciate the draft can clarify the following questions that I have.
>
> 1. The fundamental question for me is that when performing preemption across
> Class-Types, what
> is the recommendation of which Class-Types to preempt first?  Intuitively,
> the lowest priority
> is the one to pick.  However, if the lowest priority traffic does not have
> sufficient capacity
> to accommodate the higher priority, then the next lowest priority traffic is
> going to be
> bumped.  If this is the design requirement,  it may be worthwhile to
> indicate it in the draft.
> In addition, the draft should explain the requirement of how to prevent
> chain-event of
> pre-emptions to happen in the network since it creates instability during
> failure.
>
> 2. The second question that I have is the fairless of determining which LSP
> or IP packet to be
> bumped?  Any recommendation?
>
> 3. My final question is regarding the following statement in section 2.5.2
> (page 9), I am
> confused by the motivativation behind it.
>
> "DS-TE must also allow the network operator to configure the TE-LSPs so that
> pre-emption across
> Class-Types is precluded."
>
> If my understanding is correct, within the same Class-Type, fundamentally,
> it is not allowed to
> perform preemption.  Then, if configuration is available to disallow the
> pre-emption across
> Class-Types, it implies that there is no pre-emption allowed at all.   Then,
> in your first
> example when the rest of the link capacity is occupied by best effort
> traffic (e.g. 50% of EF
> and 50% of BE), how can the higher priority traffic (i.e. EF) be allowed to
> take over the low
> priority capacity (i.e. BE) even though the higher priority traffic is
> within the bandwidth
> constraints of the high-priority traffic occupancy (i.e. 50% < 70%) on that
> link?
>
> draft-ash-mpls-diffserv-te-alternative-02.txt
>
> I have two basic questions on this draft.
>
> 1. In section 3.2, although there are some brief descriptions on the intents
> of the
> "admission-control priority classes" and "restoration priority classes".  To
> me, it is still
> unclear about why these two classes are needed in order to allow higher
> priority LSP to be set
> up first and be protected first.  More explaination on the motivation on
> these types of priority
> classes would be very useful.  More importantly, how exactly they are being
> coordinated with
> each other when performing the TE function?
>
> 2. I have a lot of trouble of trying to understand how to handle the
> crankback situation for the
> example which is described in section 3.2 for the LSP setup at the ingress
> and transit LSRs.
> Since there is no mention on how each node recognizes the
> protected-CT-bandwidth level across
> the selected hops, when performing crankback, how the crankback node
> recognizes which new hop to
> select to set up the LSP.  More details on this aspect for the example would
> be extremely
> useful.
>
> That's all for now....
>
> Thanks in advance for your clarification on my questions.....
> Tricci
>
> "Lai, Wai S (Waisum), ALSVC" wrote:
>
> > Attached herewith is a diffmarked .pdf file with comments that were posted
> > some time ago to the author team of the Diffserv TE requirements draft,
> > http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-01.txt.
> > While some of the comments are purely editorial, a number of technical
> > issues have been raised.
> >
> > As a response to the following call from Jim, they are now re-posted for
> > discussion in the list.
> >
> > In addition to the comments in the attached file, the draft
> >
> http://search.ietf.org/internet-drafts/draft-ash-mpls-diffserv-te-alternativ
> > e-02.txt
> > also addresses the following two requirements:
> >
> > 1. No new LSAs used to signal per-class-type (CT) available bandwidth,
> > maximum bandwidth, preemption parameters, etc.  Rather, CT-bandwidth
> > allocated and protected by mechanisms that do not require new per-CT LSAs,
> > as illustrated in the draft.
> >
> > 2. Limit to 6 CTs, which align QoS class (Y.1541/DiffServ),
> > admission-control priority, restoration priority, preemption priority,
> > traffic type (user/control), etc.
> >
> > Your comments on any of these aspects are welcome.
> > Thanks, Wai Sum.
> >
> > -----Original Message-----
> > From: Jim Boyle [mailto:jimpb@nc.rr.com]
> > Sent: Thursday, August 23, 2001 11:35 AM
> > To: te-wg@ops.ietf.org
> > Subject: reminder: things todo in august and shortly thereafter
> >
> > From the minutes:
> >
> > o) End of August: Operators actually interested in Diffserv TE, read
> >    the requirements draft draft-ietf-tewg-diff-te-reqts-01.txt and
> >    provide feedback to list.  Would like to wrapup the requirements
> >    draft by end of August!
> >
> > o) First week of September:  After this time, please don't raise new
> >    issues with draft-team-restore-hierarchy-00.txt. The goal is to
> >    have the team revise and republish so as to be able to "hand off"
> >    to ccamp for consideration by last day of September.
> >
> >   ------------------------------------------------------------------------
> >                                                   Name:
> draft-ietf-tewg-dste-reqts-00-08.pdf
> >    draft-ietf-tewg-dste-reqts-00-08.pdf           Type: Acrobat
> (application/pdf)
> >                                               Encoding: base64
> >                                        Download Status: Not downloaded
> with message