Re: reminder: things todo in august and shortly thereafter

[Tricci So <tso@caspiannetworks.com>]

Hi Jim,

Sorry for the late response.   Please see my inserted comments below....

Cheers,
Tricci

Jim Boyle wrote:

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

[Tricci] Great.  Looking forward for the revised draft...

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

> [Tricci] I agree with you that even OSPF is "instable" as it converges.  However, there is
> "hold-off" timer designed to help to control the routing convergence stability.  On the other hand,
> there is no such timer nor any other mechanism designed to control the preemption - hence, I am not
> sure if this as transient as you think.  Especially, when there is no standard recommendation of how
> to select which traffic or LSP to preempt at each hop along the path.  Hence, different set of
> traffic or LSPs could be bumped, and the outcome would not be pretty.
>
> 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.

> [Tricci] I agree with you that preemption selection policy is an implementation issue.  However, a
> mechanism to control the instability caused by preemption should be a standard recommendation.  I
> don't believe that we have one.  I am hoping that we can first derive the requirement so that we can
> drive for the solution.
>
> 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.

> [Tricci] The centralized resource management approach as you suggested could work to reduce the
> instability, assuming there is sufficient information to allow the right decision to be made.  I am
> not sure that I understand what you mean about "second guessing"?   My concern is not whether it can
> preempt the bandwidth in another class or not, my concern is to determine how to minimze the number
> of LSPs to be disturbed along the path in order to reduce the instability effect.

> [Tricci] In my previous question #3, I am concerning the conflicting intent of the preemption
> options within the network.  I am hoping that the authors can clarify the statements that I
> referred.

[Tricci] Thanks again to your time and your pointers..... Tricci

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