Re: reminder: things todo in august and shortly thereafter

[Jim Boyle <jimpb@nc.rr.com>]

Tricci - the issue of Class Types being so extensively used in section
2 has been an item of confusion - the authors will be revisiting their use.

Here are my takes to answers on your questions:

1)  Preemption is obviously something that folks would like to use, as
    is noted in the scenarios where EF traffic can "bump" best effort
    traffic.  Esp. during failures, yes, the bumping and resignalling,
    potentially on stale information, will cause some instability,
    which are presumably just dynamic transients.  Even OSPF is
    "instable" as it converges.  There are no properties that I am
    aware of that allow for long-term instability.

2)  Determining which LSP gets bumped is of course an implementation
    issue.  If any carriers w/ experience think there are golden
    algorithms (e.g bump smallest, or longest, etc..) they should
    write up their experiences and recommendations.

3)  Although preemption is one form of operation, lack of preemption
    is also a form of operation.  It is ok if different forms of
    operation are conflicting, but it does highlight the premise of my
    draft.  Although humans like to understand the operation of the
    network in total, it is not necessary for every router to have
    total foresight into the behavior of the rest of the network, a
    limited amount of knowledge suffices.  I vary w/ Francois and
    Kireeti in stating that head end LSRs should only set up LSPs if
    bandwidth for that class of LSP is advertised as available in the
    network.  They should not be second guessing that, even though
    bandwidth for that class of LSP is not advertised on a link, they
    *should* be able to preempt bandwidth in another class.  In
    implementation today, the way I propose is actually what is done.
    It is also expressely permitted in the rsvp, ospf and isis
    drafts.

regards,

Jim


On Tue, 28 Aug 2001, Tricci So wrote:

> 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
>
>