Subject: Re: reminder: things todo in august and shortly thereafter

From: Tricci So <[email-masked]>
Date: Sun, 02 Sep 2001 21:52:06 -0700

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:[email-masked]]
> > > Sent: Thursday, August 23, 2001 11:35 AM
> > > To: [email-masked]
> > > 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
> >
> >

---

From: Tricci So <[email-masked]>
Date: Sun, 02 Sep 2001 22:25:53 -0700

Hi Jerry,

Many thanks for your info regarding Class-Type priority definitions and LSP bandwidth modification
selection example.

I can see that the amount of path computation would be very extensive with the solution that you
proposed.  May I ask, have you done any performance analysis to determine if such solution is
scalable for a large core network, let's say 10's thousands of LSPs?

Thanks again to your pointer......
Tricci

P.S.  I haven't read you crankback draft yet.  More comments will be provided once I read it.
Thanks....

"Ash, Gerald R (Jerry), ALCTA" wrote:

> Tricci,
> See comments below.
> Thanks,
> Jerry Ash
> > 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 explanation
> 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?
>
> See the attached PDF document for further explanation of our thoughts on
> class types and the role of admission control priority and restoration
> priority.  We plan to issue an I-D on this in the next few weeks.
>
> > 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.
>
> As specified in the I-D on crankback
> http://search.ietf.org/internet-drafts/draft-iwata-mpls-crankback-01.txt,
> the transit LSR can either crankback to the ingress LSR or a border LSR.  In
> the example, after a transit LSR recognizes that requirements are not met on
> the next hop (e.g., lack of sufficient available bandwidth), the transit LSR
> sends crankback to the ingress LSR.  The ingress LSR then selects another
> LSP choice, based on several possible algorithms.  The attached figure gives
> some further details of an example, see also
> http://www.ietf.org/internet-drafts/draft-ietf-tewg-qos-routing-01.txt
> (e.g., Section 3.4).
>
>                                               Name: mpls.diffserv.te.class.types.082901.pdf
>    mpls.diffserv.te.class.types.082901.pdf    Type: Acrobat (application/pdf)
>                                           Encoding: base64
>
>                                                  Name: mpls.diffserv.te.lsp.selection.example.pdf
>    mpls.diffserv.te.lsp.selection.example.pdf    Type: Acrobat (application/pdf)
>                                              Encoding: base64

---

From: [email-masked]
Date: Mon, 3 Sep 2001 11:09:05 +0100

Tricci,

The basic problem here is that there is no relationship between a given
traffic instance's up-state QoS forwarding treatment requirement and its
survivabilty requirement post-failure.  To me at least, this seems to be a
fundamantal problem with much of the DS/pre-emption discussion I have seen
so far.

For public service offerings the above is not so much of a problem *for a
given QoS/DS class type*, ie here we have common aggregation of traffic to
whatever the QoS/survivability design the operator has deigned suitable.
However, it seems an intractable problem for VPNs *if* one simply aggregates
on a like-DS class basis across all VPNs and ignores relative survivability
requirements between different VPNs.  In such a case then on failure how
does one know what fraction of what VPN gets access to the remaining
resource?  Further, the surviving traffic will be a function of what % of
which DS classes are active at the time of failure, ie this is
non-deterministic on a per VPN basis.  You cannot therefore simply allocate
survivability on some EF vs AFxy vs BE basis....hopefully this is obvious,
but to ram home the point consider this example:
-	in a single VPN the 'sales' team may have mission critical voice and
incidental data traffic, but the 'engineering' team may have opposite
requirements.  In both cases voice has to go EF class to meet jitter
requirements *whilst the network suffers no resource reduction*, but on
failure we may want to dump the 'sales' team's data traffic and we may want
dump the 'engineering' team's voice traffic to make sure the mission
critical voice/data traffic survives.

And now what about just simply comparing two different VPNs, ie a coarser
level of survivability comparison?  Maybe one VPN customer has a very high
survivability requirement (which is irrespective of his/her QoS traffic
needs) compared to another customer....so how can I, as an operator,
differentiate the SLAs in these 2 cases?

The only way to satisfactorily address these issue to to hard partition the
VPN reources on a per VPN basis (for the 2nd point above) and also to
indicate (again perhaps by recursive LSP BW partitioning, though I could
envisage other means) the relative survivability between traffic instances
within a single VPN (for the 1st point above).  Also note in the 1st point,
that the only person able to properly associate a survivability requirement
for a given traffic instance within a given VPN is the customer.  So this is
a customer-controlled policy issue.  The 2nd point is a network operator
controlled policy issue, but in this case only looking across the population
of VPNs on a relative VPN basis.....and not on a (within VPN) per traffic
instance basis.

Clearly the 1st step here is to at least get the 2nd point right.  It seems
this could be done by using a mechanism like ER/signalled LSPs with some
effective BW envelope instead of LDP LSPs as the server LSP layer for VPNs.
Ok its looks like traditional L2 VPNs but so what?....there is no free-lunch
here.

Now let's look at the pre-emption issue.  Not sure there is real benefit
from this.  Why?  Because at low traffic loads there is no issue anyway, and
at high traffic loads (when it should be earning its keep) our experience of
these mechansisms in the past has shown a very small 'predicatable' (sic)
operating region......things can get out of hand very quickly if you allow
multiple pre-emtion/bumping classes, ie a single failure can result in
multiple failures as traffic is bumped/restored across several priority
classes as the failure event ripples out from it's epicentre.  Those who
like the idea of multiple-class pre-emption/bumping should go ahead and try
it for themselves.  We would want to be able to disable any such schemes and
would just require a relative survivability indicator (ie to indicate the
priority of access to resource post-failure).  Further, and for the reasons
given previously, these would be orthogonal behavioural requirements to QoS
considerations.

regards, Neil

> From: Tricci So [mailto:[email-masked]]
> Sent: 03 September 2001 05:52
> Cc: [email-masked]'
> Subject: Re: reminder: things todo in august and shortly thereafter
> 
> 
> Hi Jim,
> 
> > "hold-off" timer designed to help to control the routing 
> convergence stability.  On the other hand,
> > sure if this as transient as you think.  Especially, when 
> there is no standard recommendation of how
> > 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.
> >
> > 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
> > > 1. The fundamental question for me is that when 
> performing preemption across Class-Types, what
> > > is the one to pick.  However, if the lowest priority 
> traffic does not have sufficient capacity
> > > If my understanding is correct, within the same 
> Class-Type, fundamentally,  it is not allowed to
> > > up first and be protected first.  More explaination on 
> the motivation on these types of priority
> > > the selected hops, when performing crankback, how the 
> crankback node recognizes which new hop to

---

From: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>
Date: Mon, 10 Sep 2001 10:35:52 -0400

Hi Tricci,

Thanks for your comments.  Please see some additional comments below.

Regards,
Jerry

> Sent: Monday, September 03, 2001 1:26 AM
> Cc: [email-masked]'

> Many thanks for your info regarding Class-Type priority definitions and
LSP
> bandwidth modification selection example.

> I can see that the amount of path computation would be very extensive with

> the solution that you proposed.  May I ask, have you done any performance 
> analysis to determine if such solution is scalable for a large core
network, 
> let's say 10's thousands of LSPs?

Yes, a comparative scalability analysis was done, and is presented in
Section 3.3 of
http://search.ietf.org/internet-drafts/draft-ash-mpls-diffserv-te-alternativ
e-02.txt.  Actually, the main point of our I-D was to point out ways to
increase the scalability of DiffServ TE.  

On a more general note, one can question scalability even without
introducing multiple class-types with DiffServ TE.  For example, see our
discussion of IGP scalability in
http://search.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-contro
l-00.txt.  In that draft we propose mechanisms to improve current IGP
scalability.