Re: OSPFv2 Opaque LSAs in OSPFv3

Kireeti Kompella <kireeti@JUNIPER.NET> Thu, 10 October 2002 18:52 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19548 for <ospf-archive@LISTS.IETF.ORG>; Thu, 10 Oct 2002 14:52:19 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0076571F@cherry.ease.lsoft.com>; Thu, 10 Oct 2002 14:54:24 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 277988 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 14:54:24 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 10 Oct 2002 14:54:24 -0400
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9AIsNm89382 for <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 10 Oct 2002 11:54:23 -0700 (PDT) (envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g9AIsNu09615 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 11:54:23 -0700 (PDT) (envelope-from kireeti)
Message-ID: <200210101854.g9AIsNu09615@kummer.juniper.net>
Date: Thu, 10 Oct 2002 11:54:23 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Kireeti Kompella <kireeti@JUNIPER.NET>
Subject: Re: OSPFv2 Opaque LSAs in OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To: <39469E08BD83D411A3D900204840EC557633BF@vie-msgusr-01.dc.fore.com>
Precedence: list

Thanks for your support, Venkata!

One thing I would like to reiterate: there are a *small* number of
currently defined Opaque LSAs -- TE, Grace LSA, and perhaps one more.
If we analyse the applicability of those LSAs to OSPF v3, and mandate
that any future definition of an OSPFv2 Opaque LSA MUST have a similar
analysis, that seems to me to address the "backdoor" problem.

The "backdoor" issue is an excellent example of a *theoretical*
problem that has little *practical* relevance, given the above mandate.

As a consequence, we have at least two independent efforts to migrate
just the TE document to v3, when in fact it should be really simple.
Then we do it again for Grace LSAs.  And possibly again in the future.

And then we hear that the IETF is overloaded, and the IESG overburdened.
Oh, well ...

Kireeti.