The MPLS WG Archive

[dwilder@baynetworks.com (David Wilder)]

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 flexible
for now.  Then we can add a supplemental draft later on with guidelines for
how these metrics should be defined.

Dave


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