The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <20030227150131.N32160@kummer.juniper.net>, Kireeti Kompella writes:
> Hi Steve,
> 
> On Thu, 27 Feb 2003, Stephen Trowbridge wrote:
> 
> > If they decide not to be involved and the other SDO goes ahead with
> > developing their own solution, they don't need to bless the extension,
> > or even like it, but they do need to accept it.
> 
> Going back to the examples that Deborah brought up: what if other SDOs
> produced variants of SDH -- would you say that the ITU "do need to
> accept it"?
> 
> Kireeti.


It really becomes a practical matter.

For example, SONET scrambling was changed because the original was too
short and too easy to send an IP packet containing the entire reverse
scramble sequence leading to all same bit after scrambling, causing a
SONET framing error.  The ease of doing this was demostrated by a BBN
engineer in network operations.  Although the push came from the IETF
to change this and there was resistance it was changed when it was
obvious that customers were going to insist on the change in products,
whether or not any SDO blessed the change.

The opposite is true in the case of ITU requirements for QoS published
in the mid 1990s.  IETF didn't like it.  No one implemented.  No
customers asked for it.  End of story.

An example where the SDO didn't accept changes and the SDO became
irrelevant wrt those specs is ISIS, where nearly 100% of implemented
and deployed ISIS is according to the IETF defined extensions to ISIS
which began with rfc1195.  ISO has never quite recognized the IETF
extensions, but no one really cares much what ISO thinks about this.

A few things have been jammed through the IETF that never went any
where.  For example, guarenteed services in RSVP, NHRP (and everything
the ROLC and ION WGs did, and most of what IPATM did), QoS routing
extensions for OSPF.  The requirements documet first is a means of
insuring better quality control over what emerges from the IETF.  (Not
in terms of "to the letter perfect" documents, but useful protocols).

The emphasis on running code and rough consensus rather than study
groups and voting has worked quite well.  There is not reason to
change it or to consider a liason comment or contribution and
different from any other contribution.

Curtis