The MPLS WG Archive[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
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 > > >
|
|