The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Backend TE Support
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.
|
|