The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Apr> msg00251



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Backend TE Support

  • From: Curtis Villamizar <curtis@avici.com>
  • Date: Thu, 27 Apr 2000 09:37:17 -0400
  • cc: curtis@avici.com, "Don Fedyk" <dwfedyk@nortelnetworks.com>, "Ghanwani, Anoop [BAY:BL60:485]" <aghanwan@baynetworks.com>, anoop@baynetworks.com, mpls@UU.NET


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.