The MPLS WG Archive

[Alia Atlas <aatlas@avici.com>]

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