Subject: New data elements for IGP traffic engineering extensions drafts

From: Ajay Kachrani <[email-masked]>
Date: Tue, 09 Mar 1999 17:36:24 -0600

We like to propose the following  three new data-elements to the
draft-ietf-isis-traffic-00.txt (isis-te), draft-yeung-ospf-traffic-00.txt
(ospf-te), and 
draft-li-mpls-igp-te-00.txt (igp-te):

a) Current fault protected bandwidth reserved: This 4-Octets value is to 
support Reserved Protected Bandwidth for "fast-reroute" specified by the 
draft-ietf-mpls-rsvp-lsp-tunnel-01.txt. Additionally, "Reroute" 
operation on Traffic Trunks has also been called out in 
draft-ietf-mpls-traffic-00.txt - "Requirements for Traffic Engineering 
Over MPLS".

b) Current link utilization: This 2-Octets value is to allow distributed 
Traffic Engineering Algorithms to dynamically re-optimize the Traffic 
Engineered Paths based on this statistics.

c) Probability of packets drop: This 2-Octets value is again to allow
Traffic Engineering Algorithms to determine congestion in the
network and therefore re-optimize the Traffic Engineered Paths.

All the three drafts included and have pointed out the stability problem 
with  flooding the "Current bandwidth reservation" data element. The 
same problem exists with item b) and c) above as pointed out by Tony Li.

Note that the statistics suggested above is necessary to perform 
"dynamic" network optimization across the entire Traffic Engineered 
Domain.

Various  techniques are available to address stability issues. It is
presumed that the stability issues referred in the IGP TE drafts are 
concerning frequent change in a data-element value resulting in to IGP 
flooding storms. 

The following two techniques have been utilized successfully in the 
traditional routing protocols addressing the stability issue: "dampen 
the data" or secondly, "flood the data-element on fixed time-interval", 
e.g. every 5, 10 or 15 minutes.

===========================================================
Ajay Kachrani						
[email-masked]
Tel:(978)964-2239
http://www.avici.com

---

From: Tony Li <[email-masked]>
Date: Tue, 9 Mar 1999 15:55:48 -0800 (PST)

Ajay,

|  We like to propose the following  three new data-elements to the
|  draft-ietf-isis-traffic-00.txt (isis-te), draft-yeung-ospf-traffic-00.txt
|  (ospf-te), and 
|  draft-li-mpls-igp-te-00.txt (igp-te):

Please write a _separate_ draft to describe your proposal.

|  Various  techniques are available to address stability issues. It is
|  presumed that the stability issues referred in the IGP TE drafts are 
|  concerning frequent change in a data-element value resulting in to IGP 
|  flooding storms. 

No, actually, the concern was more about overall stability...  solving IGP
flooding problems are a necessity for a competent IGP implementation,
irrespective of TE.

|  The following two techniques have been utilized successfully in the 
|  traditional routing protocols addressing the stability issue: "dampen 
|  the data" or secondly, "flood the data-element on fixed time-interval", 
|  e.g. every 5, 10 or 15 minutes.

Both of these techniques are know to lead to load oscillations.  You need
to address these.  Note that I am NOT saying that this is impossible.  Just
that the technology for dealing with this is not yet widely known within
the IETF.  

Tony

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 09 Mar 1999 19:30:40 -0500

> that the technology for dealing with this is not yet widely known within

Ajay, you may choose to look up a recent paper by Apostolopoulos et al.
(I think
it's in sigcomm'98) that deals with the flooding restrictions
throroughly. You'll find 
however, as Tony says, that in the global sense load oscillations are
_not_
solved by such techniques ...

	thanks 

	 -=-=t onmy

---

From: Ajay Kachrani <[email-masked]>
Date: Tue, 09 Mar 1999 20:37:48 -0600

>Please write a _separate_ draft to describe your proposal.

This will be done after the MN IETF...I would still like to discuss these 3
data elements in the working group.

>that the technology for dealing with this is not yet widely known within

How is "Current bandwidth reservation" specified in the current draft solve
the stability problems?

Thanks-
--Ajay

---

From: Tony Li <[email-masked]>
Date: Tue, 9 Mar 1999 18:15:57 -0800 (PST)

|  How is "Current bandwidth reservation" specified in the current draft solve
|  the stability problems?

I doesn't HAVE the stability problem.  Because the reserved bandwidth is a
function of the labels through the link, traffic does not 'move away' as
the link loads up.

If one were to try to balance reservations across the network, you would
have exactly the same problem.

Tony