The MPLS WG Archive

[Curtis Villamizar <curtis@avici.com>]

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