The MPLS WG Archive

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



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

Backend TE Support

  • From: dwilder@baynetworks.com (David Wilder)
  • Date: Wed, 26 Apr 2000 16:15:39 -0400 (EDT)
  • CC: curtis@avici.com, Don Fedyk <dwfedyk@nortelnetworks.com>, "Ghanwani, Anoop [BAY:BL60:485]" <aghanwan@baynetworks.com>, anoop@baynetworks.com, mpls@UU.NET

That sounds like a very good idea Bora.  

Dave

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