The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

What we can do alternatively is leave this draft as is, but start another 
draft that is "informational" and documents what metrics people are using 
and how they can be used in an SPF computation.

Does this make sense?

Bora


At 09:28 AM 4/26/00 -0400, Curtis Villamizar wrote:

>In message 
><F033F6FEF3F1D111BD150000F8CD143103D98B8E@zcard007.ca.nortel.com>, "
>Don Fedyk" writes:
> >
> > Bora
> >
> > We went through a lot of this thought process and came to the
> > conclusion that defining the place to put the metric was the
> > most we would do now. One of the rejected schemes was a metric
> > descriptor that told you the type explicitly. So a 4 byte
> > type vector could identify the metric carried and you could
> > actually do correlation if I put metric x as delay and you
> > put metric y as delay as long as we stuck to a standard
> > descriptor identifying "delay" we could interwork.
> >
> > So we currently propose an implicit definition as opposed
> > to an explicit definition. My understanding is you would
> > favor the more explicit definition. Then you need to define
> > the identifying codes and that is where the debates start.
> > I think it is like politics, the more you specific you get
> > the less people agree with you. ;-)
> >
> > Don
>
>
>Bora, Don,
>
>A compromise that seems to have worked well in diff-serv was to split
>the 6 bit space into two parts, one predefined, where some consesus
>was needed for assignement and the other was designated for
>local-assignment.
>
>The same sort of compromise would probably please the most people in
>this case as well.
>
>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. :)]
>
>Curtis