The MPLS WG Archive

["Don Fedyk" <dwfedyk@nortelnetworks.com>]

Title: RE: Backend TE Support

Curtis

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@avici.com]
> Subject: Re: Backend TE Support
>
<snip>

>
> 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
>
I would like to address this. We originally proposed multiple static
metrics for TE from a real requirement. Now we could have just gone
for one additional optional metric but the effort is rather large.
So we went for three additional to give us some breathing room. I
merely suggested that the way we've defined them that others could
use them for other things - maybe to get real working code. Perhaps
this was a mistake, although we were planning to experiment with the
additional metrics if you hadn't already guessed.

If there is disagreement, we could go for experimental but really all
we want is a few standard TLV codes that we don't have to redefine.
The other stuff can be defined later.

Don

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