The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Oct> msg00044



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

what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt

  • From: Erblichs <erblichs@earthlink.net>
  • Date: Fri, 11 Oct 2002 15:22:58 -0700
  • CC: Shahram Davari <Shahram_Davari@pmc-sierra.com>, "'Thomas D. Nadeau'" <tnadeau@cisco.com>, mpls@UU.NET

Group, and/or Shahram Davari,

	Doesn't early implementations of functionality always
	involve some risk that standard organizations will not
	accept the implementation?

	If the company is big-enough and they distribute
	enough copies of that functionality, then they use
	their customer-base to create a defacto-standard.

	Else, the company risks either being incompatible with
	the stardard, supporting multiple variations,
	or reverting their code to the now agreed upon standard.

	Thus, I don't know why Juniper doesn't release a Informational
	RFC on their implementation and the wg for this draft consider
	what should be done with the "path-specific method" to either
	achieve consensus or....
	

	Mitchell Erblich
	======================
	

Alia Atlas wrote:
> 
> What about making the method an informational part of the draft, with the
> sender-template-specific method a SHOULD?  In that way, the information
> about what was been done in the past will be preserved and inter-operable
> implementations can be made, but only as long as the interoperability with
> the path-specific method matters to someone.
> 
> Alia
> 
> At 07:09 AM 10/11/2002 -0700, Shahram Davari wrote:
> >Unfortunately I did not see any consensus? and in fact I saw many
> >objections. Therefore since no consensus exits for path-specific method,
> >it has to be taken out of the draft.
> >
> >-Shahram
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > > Sent: Friday, October 11, 2002 9:10 AM
> > > To: Shahram Davari
> > > Cc: mpls@UU.NET
> > > Subject: RE: what's the status of
> > > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt
> > >
> > >
> > >
> > > > > As for the path-specific method, we cannot take it out
> > > for a simple
> > > > > reason, that is, it is how Juniper had implemented and
> > > > > deployed.
> > > >
> > > >Although I have tried this a couple of times, but let me do it again:
> > > >
> > > >IETF is a standard organization. It is not a place to rubber stamp
> > > >individual companies implementations, but rather a place to
> > > figure out
> > > >the best solutions for the industry.
> > > >
> > > >There is always a risk of implementing a technology before
> > > it is standardized.
> > > >If we go by your logic then every implementation in the
> > > field must be
> > > >standardized !
> > > >
> > > >Does that make sense?
> > >
> > >          Sharam,
> > >
> > >          At the risk of repeating myself and others on the
> > > topic, remember the
> > > IETF mantra: working code and rough consensus.   This is to a
> > > large part
> > > why the Internet works today and is still not a research project.
> > >
> > >          --Tom
> > >
> > >
> > > Success is relative; the more success, the more relatives. -Anonymous
> > >