Re: OSPFv2 Opaque LSAs in OSPFv3

"Naidu, Venkata" <Venkata.Naidu@MARCONI.COM> Mon, 14 October 2002 14:20 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 KAA21474 for <ospf-archive@LISTS.IETF.ORG>; Mon, 14 Oct 2002 10:20:56 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0076EB00@cherry.ease.lsoft.com>; Mon, 14 Oct 2002 10:11:25 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 290936 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Oct 2002 10:11:25 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 14 Oct 2002 10:11:25 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08616 for <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 14 Oct 2002 10:10:52 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10802 for <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 14 Oct 2002 10:10:03 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4W8J4VGF>; Mon, 14 Oct 2002 10:10:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID: <39469E08BD83D411A3D900204840EC557633DC@vie-msgusr-01.dc.fore.com>
Date: Mon, 14 Oct 2002 10:09:59 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Naidu, Venkata" <Venkata.Naidu@MARCONI.COM>
Subject: Re: OSPFv2 Opaque LSAs in OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Dennis,

-> If the IESG thinks of "OSPFv3" as exclusively "IPv6" I think
-> they might be missing some of the bigger picture with respect
-> to future operational requirements for an IGP.

 One of my recent mail to another list strongly supports
 these points.

FYI -

-----Original Message-----
From: Naidu, Venkata [mailto:Venkata.Naidu@marconi.com]
Subject: RE: [diff-ospf-isis] Points from 1991 paper

-> However it is just as easy to add IPv4 support for OSPFv3 ...
-> .... ;-) Though no-one would attempt it backwards.

  There are lot of advantages if one does IPv4 support for OSPFv3.
  That is what is my recent mail in OSPF-WG, but unfortunately
  AD rejected my attempt to convince :)

  Everyone thinks that OSPFv3 is for IPv6 - that is very wrong.
  In a layered architecture, one can (at least in *theory*) remove
  each layer an replace it with something new, enhanced protocol
  with out disturbing the lower/upper layer protocols. That is
  the beauty of layering.

  If one does the way suggested, then all the "IPv4 applications" of
  OSPF (I should say IGPs) performance will increase tremendously.
  In other words, OSPFv3 is designed such a way that all the
  "good experience" we got from OSPFv2 are rectified/beautified/improved.
  (I know that because the OSPFv3 is created in the same group
   I am working right now).

  That view of looking at IGPs as just "hop-by-hop routing protocols"
  should go away. Now with the new opened doors in Optical networking,
  Advanced (diffserv) TE enhancements, VPNs, those good old IGPs became
  like transport protocols. The applicability of these IGPs for
  transportation of transparent data will increase in future years.
  May be, we (IGP guys) should get a big picture of how/why/what TSVWG
  is doing for new requirement in transport protocols (such as SCTP
  etc etc). How can we do the same stuff with minimal changes in IGPs
  for the benefit of our "IGPs applications" ?

  Finally, the % of code in IGPs used for SPF and hop-by-hop routing
  table calculations is decreased. That % is grabbed by other
  purposes. IGPs are no more self-driven, rather dictated by some new
  applications requirements.

  If we fail to tune our IGPs for all such applications then, new
  protocols will emerge (for example, LDP). Those new XXX protocols
  will look exactly like "stripped OSPF" - in 1000ft view.

  PS: I know, LDP does more than "tailored OSPF" for label distribution.
      I just gave an example :-)

--
Venkata.