The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

Curtis

Aren't we generalizing here?

I am interested in seeing an implementation of a routing protocol that is 
sensitive to the status of the network instead of being static. Unlike OMP 
however, I would like to start simple by not creating hot spots first and 
then build on it.

I have reviewed the OMP work extensively about one year ago and agree that 
it has merit, on the other hand it can benefit from theoretical analysis of 
stability of the filters that are employed on the link utilization instead 
of defining a set of  filters that work in a simulation environment but may 
not work for all networks under all conditions. (I think such an analysis 
would make an excellent thesis topic by the way)

I think that the SIGCOMM 89 paper by Zhinky and Khanna is a good starting 
point on applying control theory concepts and methods to analyzing a 
dynamic metric, and should be reviewed by all that are interested in 
dynamic network-sensitive routing in the Internet.

The fact that Don et al. had started work on a set of metrics that can be 
flooded as part of the LSPs means that I can use their mechanisms to 
implement my simple load-sensitive routing protocol.

So I don't see any point on not supporting flooding of four (essentially) 
opaque metrics. OMP surely can use them too , right?

Anyway, as I said before, I think that there is a lot of work to be done in 
the area of traffic engineering that does and does not use MPLS. I think 
the WG needs to be supportive of such developments. (Of course according to 
the charter of the WG, if these topics are not included, we should take 
them elsewhere)

Regards

Bora




At 11:20 AM 4/27/00 -0400, Curtis Villamizar wrote:

>In message <200004271432.KAA18591@bubba.engeast>, David Wilder writes:
> > Aren't we going down a rathole here?  The discussion on what metrics to put
> > in and how to define them can go on forever.  I agree with Bora.  Let's
> > move ahead with putting in the extra metrics; leaving the definitions 
> flexibl
> > e
> > for now.  Then we can add a supplemental draft later on with guidelines for
> > how these metrics should be defined.
> >
> > Dave
>
>
>Dave,
>
>I was just responding to the "Any volunteers?" question from Bora
>which seemed likely to be directed to me as a result of the "It might
>also be necessary ..." comment.
>
>I don't want to be an obstructionist but I do want to point out that
>there is a reason for my not wanting to add to or support this work
>unless it is better defined.  We'll have to see if WG consensus is
>with you to move forward with this.
>
>I am also pointing to OMP as an example of a use of additional metrics
>which for better or worse, is well defined.  I strongly believe in
>having "working code and first" and then advancing a document so I've
>presented OMP, will implement, then ask for advancement as
>experimental, then only after deployment suggest standards track
>advancement.  Don, Bora, and others, seem taking the opposite approach
>in defining protocol with the intemtion of later determining a use for
>it.  In the past the IETF has insisted that things be well thought out
>and documented and has avoided protocol options with uncertain usage.
>
>Curtis
>
>
> > > In message <4.3.1.2.20000426155007.00b09700@localhost>, Bora Akyol 
> writes:
> > > > OK!
> > > >
> > > > I would be willing to author/co-author/edit such a draft, but would 
> need
> > > > help on defining the metrics and formulating them to fit the TLVs, 
> LSAs e
> > tc.
> > > >
> > > > Any volunteers?
> > > >
> > > > Bora
> > >
> > >
> > > Bora,
> > >
> > > Perhaps you missed this prior comment:
> > >
> > >    I don't mean to lend my support for this proposal by commenting and
> > >    suggesting a compromise.  By introducing too much protocol which is
> > >    partially defined, and possibly not well enough thought out, we
> > >    could be creating the standards process equivalent of a Tower of
> > >    Babel.  [Which might not be policially correct since that's ISO
> > >    territory. :)]
> > >
> > > I am not in favor of a draft which defines information to be
> > > advertised with no stated purpose.  This is a lot like the old TOS
> > > bits, which all sounded like a great idea.  I recall, cost,
> > > throughput, delay, and what was the other one.  They never got used.
> > > IP is fortunate to have minimized such baggage, unlike OSI.
> > >
> > > OTOH, I do expect to be working on an MPLS-OMP implementation (RSN?)
> > > and will resubmit the OSPF-OMP and MPLS-OMP drafts for consideration
> > > again by the respective work groups.  The OSPF WG seems inclined to
> > > advance the OSPF-OMP as experimental, but I'd prefer to split it in
> > > two, one on flooding, one on OSPF-OMP forwarding.  The MPLS-OMP work
> > > relies on the OSPF-OMP flooding only.  There was also a very small
> > > ISIS-OMP draft which needs to be revised since the sub-TLVs used
> > > conflict with sub-TLVs later taken by ISIS TE extensions for CR.
> > >
> > > Curtis
> > >
> > >
> > > > >It might also be necessary to provide some sort of advice or
> > > > >conventions on flooding frequency since flooding frequency will
> > > > >substantially affect many algorithms.  Attempts to provide a high
> > > > >degreee of adaptivity can either react very slowly or too quickly and
> > > > >go unstable if the flooding frequency and the adaptivity reaction time
> > > > >are not well matched.
> >
> >