RE: reminder: things todo in august and shortly thereafter

["Lai, Wai S (Waisum), ALSVC" <wlai@att.com>]

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