Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 8 Oct 2002 12:40:23 -0400

Hi Kireeti,

>> Though I agree the approach you suggest does minimize the amount of
effort
>> for the working group to get similar functionality in OSPFv3 as OSPFv2,
by
>> simply ignoring the OSPFv2 header(i.e. first 20 bytes of the payload).

> Not entirely accurate: the OSPFv2 header (if you mean the LSA header) is
> almost identical; the LS type field is the only thing that changes.
Ok. I thought you meant you were copying the entire OSPFv2 LSA and not just
the payload. So agree that the Opaque OSPFv2 for OSPFv3 LSA we would have
the same value of Opaque type etc too.

>> I prefer a cleaner approach from the protocol implementations point of
view.
>> Probably giving an LSA type to Area Scope TE LSA's and using the Link ID
as
>> instance id.

>If you were to add "and keep the LSA body identical between OSPFv2 TE
>LSA and the new OSPFv3 TE LSA", I'd be inclined to agree with you.

That is exactly what I meant earlier(however changed views, for simplicity
and work overload for the group). The use of TLV's themselves could be the
same as that of the v2 Opaque LSA's. I think that is what you mean in the
draft Section 2. ;-)

> However, having gone that far, why not import all OSPFv2 Opaque LSAs
> into v3 in one go?  For example, you get Grace LSAs for free; if
> tomorrow someone were to invent yet another OSPFv2 Opaque LSA, you get
> that for free too, should you desire it.
Agreed it would be far simpler.

> Apropos of nothing, it's amusing that the only instance of an OSPF v3
> LSA that really fully uses the separation of flooding scope and LS
> function code is the 'OSPFv2 Opaque LSA' -- all other function codes
> have pre-defined flooding scopes.

I agree. As the LSA function codes of the RFC2740 LSA's themselves tell the
flooding scope (i.e. LSA in any other flooding scope would not make sense).

Thanks,
Vishwas

---

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 8 Oct 2002 13:11:28 -0400

Hi Acee,

> Completely agree. Could you put this in draft form? This is at least
> the second time the question of opaque LSAs and OSPFv3 has been raised.
Agreed, may be asked more often than that. I could put it in a draft for
sure.

> Since opaque LSA's are meant to be used for many applications and the
setting
> of the U bit is based solely on the function code, I'm not sure that a
> TE specific argument is a good reason for not setting the U bit.

I think the advantage of flooding optimizations(during migration - which is
how we would want it, not flood TE LSA's(which would be many in number)
between disjoint TE domains within an area) could easily be got if we had a
different code for generic opaque LSA's and TE LSA's and that is what I was
thinking of earlier. Besides we may want to define some v3 specific TLV's(as
Kunihiro pointed out).

However if we intend to go in for a generic mechanism(as in kireeti's draft)
we should instead set the U-bit. I can think of the OSPF-PCSD draft where we
may want the U-bit set.

Thanks,
Vishwas

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]]
> Sent: Tuesday, October 08, 2002 8:49 AM
> To: [email-masked]
> Subject: Re: OSPFv2 Opaque LSAs in OSPFv3
>
>
> Kireeti Kompella wrote:
>
>
>>Hi Kunihiro,
>>
>>
>>
>>>BTW I haven't submitted the draft but I prepared TE extensions to
>>>OSPFv3.  I just define a new LS type for TE then use OSPFv3 built in
>>>flooding mechanism.  I believe this is straight forward way to do it.
>>>
>>>
>>The draft I submitted also uses the OSPFv3 built in flooding.  It is the
>>only way to do it.
>>
>>
>>
>>>LSA function code  LS Type  Description
>>>--------------------------------------------------------------------
>>>10                 0x2000a  Traffic-Engineering-LSA
>>>
>
>
>
> Kunihiro,
>
> Believe you mean 0x200a.
>
>
>
>
>>Do you plan to have a different Function Code for each OSPFv2 Opaque LSA
>>Type?
>>
>
>
> Kiretti,
>
> If you take into account changes to the LS type for OSPFv3, the code
points
> are compatible. For OSPFv3, the LS Type is 16 bits (versus 8 for OSPFv2)
and
> it
> contains the flooding scope and a bit indicating what to do with
> unrecognized
> types. There are no LS type collisions pervent use of the same function
> codes.
>
>
>                                 OSPFv2             OSPFv3
>    Link Scoped Opaque LSAs        0x09             0x0009
>
>   Area Scoped Opaque LSAs        0x0a             0x200a
>
>    AS   Scoped Opaque LSAs        0x0b             0x400b
>
> One could argue that the functions types for area and AS scoped opaque
LSAs
> should be 0xa00a and 0xc00b as well. This would indicate that a router
that
> does not recognize the type should store and flood it anyway. Any strong
> feelings
> on this?
>
> Thanks,
> Acee
>
>>It seems to me to be much easier to have a single code point for all
>>OSPFv2 Opaque LSAs.  This way, all defined OSPFv2 Opaque LSAs get
>>automatically defined in v3; moreover, if a new Opaque LSA seems to be
>>useful for both v2 and v3, it can be defined as an OSPFv2 Opaque LSA.
>>
>>Kireeti.
>>
> --
> Acee
>
>

--
Acee

---

From: Alex Zinin <[email-masked]>
Date: Tue, 8 Oct 2002 17:26:27 -0400

Kireeti, et al

 Sorry for the delay.

 If I understand Kireeti's idea correctly, the suggestion is to "map"
 the Opaque LSA mechanism in v2 to the generic scoped flooding
 mechanism in v3; and it is primarily driven by the desire to get TE
 extensions to v3 faster. Below is my view on this.

 It seems to me that such a mapping would introduce the under-
 specification problem and thus may affect interoperability. Here's
 why.

 What is being said is essentially "whatever Opaque LSAs have been
 introduced in the past or will be introduced in the future in v2 now
 also make sense in v3". It's not that easy though. Opaques LSAs used
 in v2 may affect protocol mechanisms that are specific to v2 and are
 not applicable in v3, or they may contain information that makes
 sense in the IPv4 world only. Just saying that we now have this stuff
 in v3 is not enough, one has to go and specify how this info is
 interpreted there.

 In other words, when one wants to have a feature in v3 that is
 supported in v2 using Opaque LSAs, two things need to be specified:
 how required information is carried around, and how this information
 is interpreted. Suggested mapping solves the first part, which is a
 non-issue btw, but creates a problem in the second.

 Bottom line: I think there is a problem in the suggested approach and
 believe that bringing the features based on/contents of Opaque LSAs
 to v3 should be done on a case-by-case basis with proper
 specification of IPv6 and v3-related details.

 Regards.

--
Alex

---

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 9 Oct 2002 06:12:36 -0400

Hi Acee/folks,

> the second time the question of opaque LSAs and OSPFv3 has been raised.

Ok just to start to get the ball rolling, I am attaching a rip-off of the
Katz Yeung draft for OSPFv3.

The main points are : -
a) New LSA type defined
b) U-bit set to 0
c) Whereever IP address was used, has been changed.

I guess we can do with reference to the Katz-yeung draft and other TE
drafts. However for now I have left stuff as it is.

Kireeti/Kunihiro or anyone else willing to help please let me know.

Thanks,
Vishwas

=========================================================

Network Working Group                             Vishwas Manral
Internet Draft                                    Netplane Systems
Category: Standards Track                         October 2002

Expires: March 2003
draft-manral-ospfv3-traffic-00.txt

            Traffic Engineering Extensions to OSPF Version 3
                             *** Draft ***

Status

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes extensions to the OSPF protocol version 3 to
   support intra-area Traffic Engineering, using a new OSPFv3 [RFC2740]
   LSA type called Intra-Area-TE-LSA.

1. Introduction

   This document specifies a method of adding traffic engineering
   capabilities to OSPF Version 3 [1].  The architecture of traffic
   engineering is described in [2].  The semantic content of the
   extensions is essentially identical to the corresponding extensions
   to IS-IS and OSPFv2[katz-yeung-draft].  It is expected that the traffic
   engineering extensions to OSPFv3 will continue to mirror those in
   OSPFv2.

   The extensions provide a way of describing the traffic engineering
   topology (including bandwidth and administrative constraints) and
   distributing this information within a given OSPFv3 area.  This
   topology does not necessarily match the regular routed topology,
   though this proposal depends on Network LSAs to describe multi-access
   links.

1.1. Applicability

   Many of the extensions specified in this document are in response to
   the requirements stated in [2], and thus are referred to as "traffic
   engineering extensions", and are also commonly associated with MPLS
   Traffic Engineering.  A more accurate (albeit bland) designation is
   "extended link attributes", as what is proposed is simply to add more
   attributes to links in OSPFv3 advertisements.

   The information made available by these extensions can be used to
   build an extended link state database just as router LSAs are used to
   build a "regular" link state database; the difference is that the
   extended link state database (referred to below as the traffic
   engineering database) has additional link attributes.  Uses of the
   traffic engineering database include:

      o monitoring the extended link attributes;
      o local constraint-based source routing; and
      o global traffic engineering.

   For example, an OSPFv3-speaking device can participate in an OSPFv3
   area, build a traffic engineering database, and thereby report on the
   reservation state of links in that area.

   In "local constraint-based source routing", a router R can compute a
   path from a source node A to a destination node B; typically, A is R
   itself, and B is specified by a "router address" (see below).  This
   path may be subject to various constraints on the attributes of the
   links and nodes that the path traverses, e.g., use green links that
   have unreserved bandwidth of at least 10Mbps.  This path could then
   be used to carry some subset of the traffic from A to B, forming a
   simple but effective means of traffic engineering.  How the subset of
   traffic is determined, and how the path is instantiated is beyond the
   scope of this document; suffice it to say that one means of defining
   the subset of traffic is "those packets whose IP destinations were
   learned from B", and one means of instantiating paths is using MPLS
   tunnels.  As an aside, note that constraint-based routing can be NP-
   hard, or even unsolvable, depending on the nature of the attributes
   and constraints and thus many implementations will use heuristics.
   Consequently, we don't attempt to sketch an algorithm here.

   Finally, for "global traffic engineering", a device can build a
   traffic engineering database, input a traffic matrix and an
   optimization function, crunch on the information, and thus compute
   optimal or near-optimal routing for the entire network.  The device
   can subsequently monitor the traffic engineering topology and react
   to changes by recomputing the optimal routes.

1.2. Limitations

   As mentioned above, this document specifies extensions and procedures
   for intra-area distribution of Traffic Engineering information.
   Methods for inter-area and inter-AS (Autonomous System) are not
   discussed here.

   The extensions specified in this document capture the reservation
   state of point-to-point links.  The reservation state of multiaccess
   links is not accurately reflected, except in the special case that
   there are only two devices in the multiaccess subnetwork.

   This document also does not support unnumbered links.  This
   deficiency is addressed in [4]; see also [5] and [6].

1.3. Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [7].

2. LSA Format

2.1. LSA type

   This extension makes use of a new OSPFv3 LSA type called
   Intra-Area-TE-LSA. The LSA function code of which is 10 and
   the LSA type value is 0x200a.

   The U-bit of the LSA has been set to 0. This helps prevent flooding
   of Intra-Area-TE-LSA's to other routers within the area which do not
   support the LSA type.

2.2. LSA ID

   The LSA ID field is used to identify different Intra-Area-TE-LSA's.
   A maximum of 4294967296 Traffic Engineering LSAs may be sourced
   by a single system.  The LSA ID has no topological significance.

2.3. LSA Format Overview

2.3.1. LSA Header

   The Traffic Engineering LSA starts with the standard LSA header. The
   values of the fields of significance in the header have been defined
above.

2.3.2. TLV Header

   The LSA payload consists of one or more nested Type/Length/Value
   (TLV) triplets for extensibility.  The format of each TLV is:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Type             |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Value...                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length field defines the length of the value portion in octets
   (thus a TLV with no value portion would have a length of zero).  The
   TLV is padded to four-octet alignment;  padding is not included in
   the length field (so a three octet value would have a length of
   three, but the total size of the TLV would be eight octets).  Nested
   TLVs are also 32-bit aligned.  Unrecognized types are ignored.

   This memo defines Types 1 and 2.  See the IANA Considerations section
   for allocation of new Types.

2.4. LSA payload details

   An LSA contains one top-level TLV.

   There are two top-level TLVs defined:

     1 - Router Address
     2 - Link

2.4.1. Router Address TLV

   The Router Address TLV specifies a stable IP address of the
   advertising router that is always reachable if there is any
   connectivity to it.  This is typically implemented as a "loopback
   address"; the key attribute is that the address does not become
   unusable if an interface is down.  In other protocols this is known
   as the "router ID," but for obvious reasons this nomenclature is
   avoided here.  If a router advertises BGP routes with the BGP next
   hop attribute set to the BGP router ID, then the Router Address
   SHOULD be the same as the BGP router ID.

   If IS-IS is also active in the domain, this address can also be used
   to compute the mapping between the OSPFv3 and IS-IS topologies.  For
   example, suppose a router R is advertising both IS-IS and OSPF
   Traffic Engineering LSAs, and suppose further that some router S is
   building a single Traffic Engineering Database (TED) based on both
   IS-IS and OSPFv3 TE information.  R may then appear as two separate
   nodes in S's TED; however, if both the IS-IS and OSPFv3 LSAs generated
   by R contain the same Router Address, then S can determine that the
   IS-IS TE LSA and the OSPFv3 TE LSA from R are indeed from a single
   router.

   The router address TLV is type 1, and has a length of 16, and the
   value is the sixteen octet IPv6 address.  It must appear in exactly one
   Traffic Engineering LSA originated by a router.

   The address used cannot be a link-local address.

2.4.2. Link TLV

   The Link TLV describes a single link.  It is constructed of a set of
   sub-TLVs.  There are no ordering requirements for the sub-TLVs.

   Only one Link TLV shall be carried in each LSA, allowing for fine
   granularity changes in topology.

   The Link TLV is type 2, and the length is variable.

   The following sub-TLVs are defined:

     1 - Link type (1 octet)
     2 - Link ID (variable octets)
     5 - Traffic engineering metric (4 octets)
     6 - Maximum bandwidth (4 octets)
     7 - Maximum reservable bandwidth (4 octets)
     8 - Unreserved bandwidth (32 octets)
     9 - Administrative group (4 octets)
     103 - Local interface IP address (16N octets)
     104 - Remote interface IP address (16N octets)

   This memo defines sub-Types for OSPFv3.  See the IANA Considerations
   section for allocation of new sub-Types.

   The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
   exactly once.  All other sub-TLVs defined here may occur at most
   once.  These restrictions need not apply to future sub-TLVs.
   Unrecognized sub-TLVs are ignored.

   Various values below use the (32 bit) IEEE Floating Point format.
   For quick reference, this format is as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|    Exponent   |                  Fraction                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where S is the sign; Exponent is the exponent base 2 in "excess 127"
   notation; and Fraction is the mantissa - 1, with an implied binary
   point in front of it.  Thus the above represents the value
        (-1)**(S) * 2**(Exponent-127) * (1 + Fraction)

   For more details, refer to [9].

2.5. Sub-TLV Details

2.5.1. Link Type

   The Link Type sub-TLV defines the type of the link:

       1 - Point-to-point
       2 - Multiaccess

   The Link Type sub-TLV is TLV type 1, and is one octet in length.

2.5.2. Link ID

   The Link ID sub-TLV identifies the other end of the link.  For point-
   to-point links, this is the Router ID of the neighbor.  For
   multiaccess links, this is the interface ID of the designated
   router.

   The Link ID sub-TLV is TLV type 2, and is four or 16 octets octets in
   Length, depending on the link type.

2.5.3. Local Interface IP Address

   The Local Interface IP Address sub-TLV specifies the IP address(es)
   of the interface corresponding to this link.  If there are multiple
   local addresses on the link, they are all listed in this sub-TLV. Are we
   required to advertise the Link-local-Addresses too.(I guess not)

   The Local Interface IP Address sub-TLV is TLV type 3, and is 16N
   octets in length, where N is the number of local addresses.

2.5.4. Remote Interface IP Address

   The Remote Interface IP Address sub-TLV specifies the IP address(es)
   of the neighbor's interface corresponding to this link.  This and the
   local address are used to discern multiple parallel links between
   systems.  If the Link Type of the link is Multiaccess, the Remote
   Interface IP Addess is set to 0.0.0.0 .

   The Remote Interface IP Address sub-TLV is TLV type 4, and is 16N
   octets in length, where N is the number of neighbor IPv6 addresses.

2.5.5. Traffic Engineering Metric

   The Traffic Engineering Metric sub-TLV specifies the link metric for
   traffic engineering purposes.  This metric may be different than the
   standard OSPF link metric.  Typically, this metric is assigned by a
   network admistrator.

   The Traffic Engineering Metric sub-TLV is TLV type 5, and is four
   octets in length.

2.5.6. Maximum Bandwidth

   The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that
   can be used on this link in this direction (from the system
   originating the LSA to its neighbor), in IEEE floating point format.
   This is the true link capacity.  The units are bytes per second.

   The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in

2.5.7. Maximum Reservable Bandwidth

   The Maximum Reservable Bandwidth sub-TLV specifies the maximum
   bandwidth that may be reserved on this link in this direction, in
   IEEE floating point format.  Note that this may be greater than the
   maximum bandwidth (in which case the link may be oversubscribed).
   This SHOULD be user-configurable; the default value should be the
   Maximum Bandwidth.  The units are bytes per second.

   The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four
   octets in length.

2.5.8. Unreserved Bandwidth

   The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth
   not yet reserved at each of the eight priority levels, in IEEE
   floating point format.  The values correspond to the bandwidth that
   can be reserved with a setup priority of 0 through 7, arranged in
   increasing order with priority 0 occurring at the start of the sub-
   TLV, and priority 7 at the end of the sub-TLV.  The initial values
   (before any bandwidth is reserved) are all set to the Maximum
   Reservable Bandwidth.  Each value will be less than or equal to the
   Maximum Reservable Bandwidth.  The units are bytes per second.

   The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in
   length.

2.5.9. Administrative Group

   The Administrative Group sub-TLV contains a 4-octet bit mask assigned
   by the network administrator.  Each set bit corresponds to one
   administrative group assigned to the interface.  A link may belong to
   multiple groups.

   By convention the least significant bit is referred to as 'group 0',
   and the most significant bit is referred to as 'group 31'.

   The Administrative Group is also called Resource Class/Color [2].

   The Administrative Group sub-TLV is TLV type 9, and is four octets in
   length.

3. Elements of Procedure

   Routers shall originate Traffic Engineering LSAs whenever the LSA
   contents change, and whenever otherwise required by OSPF (an LSA
   refresh, for example).  Note that this does not mean that every
   change must be flooded immediately; an implementation MAY set
   thresholds (for example, a bandwidth change threshold) that trigger
   immediate flooding, and initiate flooding of other changes after a
   short time interval.  In any case, the origination of Traffic
   Engineering LSAs SHOULD be rate-limited to at most one every
   MinLSInterval [1].

   Upon receipt of a changed Traffic Engineering LSA or Network LSA
   (since these are used in traffic engineering calculations), the
   router should update its traffic engineering database.  No SPF or
   other route calculations are necessary.

4. Compatibility Issues

   There should be no interoperability issues with routers that do not
   implement these extensions. OSPFv3 [RFC2740] already defines ways
   to handle unknown LSA types. As the U-bit is not set the LSA is treated
   as a Link-Local LSA by a router which does not understand the LSA type.

   The result of having routers that do not implement these extensions
   is that the traffic engineering topology will be missing pieces;
   however, if the topology is connected, TE paths can still be
   calculated and ought to work.

5. Normative References

6. Informative References

7. Security Considerations

   This document specifies the contents of Intr-Area-TE LSAs in OSPFv3.
   As the LSA's are not used for SPF computation or normal routing, the
   extensions specified here have no affect on IP routing.  Tampering
   with TE LSAs may have an effect on traffic engineering computations,
   however, and it is suggested that whatever mechanisms are used for
   securing the transmission of normal OSPFv3 LSAs be applied equally
   to all TE LSA's.

8. IANA Considerations

9. Authors' Addresses

   Vishwas Manral
   Netplane Systems,
   189, Prashasan Nagar,
   Road Number 72,
   Jubilee Hills,
   Hyderabad - 33
   INDIA

10. IPR Notices

11. Full Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

---

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 9 Oct 2002 10:47:37 -0400

Hi Kunihiro Ishiguro,

The Link-Id is supposed to identify the other end of the link not just
Network LSA(which is originated only for multiaccess links). So for
Point-to-Point links it would be the router-ID alone(4-bytes). While for
multiaccess links it would be the router-ID and the Interface-Id(8-bytes).
Isnt that the case?

Thanks for the comment. Please let me know if you have any other comments on
the draft I have posted.

Thanks,
Vishwas

-----Original Message-----
From: Kunihiro Ishiguro [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 8:09 PM
To: Manral, Vishwas
Cc: Mailing List
Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

>One small correction Link-ID sub TLV length would always be 4-bytes i.e.
>Interface ID or Router Id of neigbor.

Interface ID or Router Id is not enough to identify Network-LSA in
OSPFv3.  Would you mind to check my draft
draft-ishiguro-ospf-ospfv3-traffic-00.txt?  I've submitted it last
night.  Hopefully it will be accepted soon.

3.1 Neighbor ID

   In OSPFv2, Link ID is unique key to identify Network LSA.  In OSPFv3
   to identify Network LSA, the combination of Neighbor Interface ID and
   Neighbor Router ID is needed.  So new sub-TLV Neighbor ID is defined.

   The Neighbor ID sub-TLV is TLV type 9, and is 8 octets in length.  It
   contains 4 octet Neighbor Interface ID following 4 octet Neighbor
   Router ID.  Neighbor Interface ID and Neighbor Router ID value is
   same as described in [OSPFV3] A.4.3 Router-LSAs.
--
Kunihiro Ishiguro

---

From: "Manral, Vishwas" <[email-masked]>
Date: Mon, 14 Oct 2002 13:43:31 -0400

Hi Dennis,

I guess it is clear that OSPFv3 is protocol agnostic and that we should be
able to carry both IPV4 and IPv6 TLV's in both OSPFv2-Opaque's and OSPFv3.

However are you also suggesting we have Inter-Area-Prefix-LSA,
Intra-Area-Prefix-LSA and Link LSA equivalents for IPv4 in OSPFv3? Or is it
just for the transport part(e.g Opaque LSA's) you feel that we have to be
able to carry both protocol TLV's.

Thanks,
Vishwas

-----Original Message-----
From: Dennis Ferguson [mailto:[email-masked]]
Sent: Sunday, October 13, 2002 4:49 AM
To: [email-masked]
Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

Alex,

> > 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.
>
> OSPFv3- and IPv6-related issues should be considered and specified for
> each feature independently, because OSPFv? are not just two versions
> of a transport mechanism, they are two different routing protocols
> providing connectivity for different types of environment.

Here's the problem I have with this.  OSPFv3 was in fact designed to
be network-protocol agnostic, like IS-IS, except retaining OSPF's
style of adjacency synchronization and many-LSA information distribution.
This is why address information was entirely separated from adjacency
maintenance packets and topology description LSAs, why there's a "v6"
option bit (so you could have a v4-only router running the protocol), is
one of the reasons for the instance ID (if you really needed to deal
with multiply-addressed v4 links), and is why the LSAs which do carry
address information only carry address information, and nothing else.
While it has not been specified yet, making OSPFv3 route IPv4 may not
be much more difficult than finding all the LSA types which carry IPv6
addresses in the current protocol (I think there are 4 of them) and
inventing equivalents to carry IPv4 addresses.

The reason I think you really want to plan for this is that networks
which support IPv6 will almost certainly continue to support IPv4 just
about forever, in Internet years.  Support for both protocols won't be
a transition strategy, it will be a permanent operational state.  As
such (and while at least one of the authors of the OSPFv3 RFC might
disagree), I don't think running two IGPs over the same topology is a
practical plan to address this.  Not only does it substantially
increase configuration, debugging and other operational complexity, but
it also unnecessarily duplicates the mechanisms which often dominate the
cost of running a link state protocol and most severely limit its
scalability,
i.e. adjacency maintenance.  Having one IGP carry twice the number of
addresses is much cheaper, more maintainable and more scalable then running
two IGPs.

So we're in this state where OSPFv3 should be a dual-network-protocol
routing protocol, but isn't yet, and you are talking about importing several
functions from OSPFv2 which, if well done, seem like they should have
very little dependence on a particular network protocol.  Given what OSPFv3
may become I think it would be a big mistake to allow gratuitous IPv6
dependencies to creep into these (in fact I also think it is a mistake
if the authors of the OSPFv2 versions let gratuitous IPv4 dependencies
creep into those) because if you do you may be painting yourself into
a corner where you might not want to be in future.

This leaves the practical problem of ensuring that functionality is
specified in a way which makes sense in a multi-network-protocol
environment when OSPFv3 doesn't (yet) operate in an environment like
that.  While one could attempt to do this in theory, I'd just point
out that if you could manage to import the functionality from OSPFv2
without changes you'd have some practical assurance that what you had
actually would make sense for IPv4 as well as IPv6.  While I'll admit
that OSPFv3 is a somewhat different routing protocol than OSPFv2, I don't
think I'd reject the direct copy based on a generic "different types of
environment" argument since those environments may become a lot more
similar in future.

> > And then we hear that the IETF is overloaded, and the IESG overburdened.
> > Oh, well ...
>
> Thanks for thinking about the IESG. I can assure you that it will be
> much less controversial (and hence faster) for the IESG to deal with
> drafts explicitly specifying IPv6/OSPFv3 considerations for specific
> features, than it will be to waste time arguing about a draft that
> collectively migrates all present and future OSPFv2-based features and
> "applications" to the IPv6/OSPFv3 environment.

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.  Perhaps there needs to be a draft to keep
people reminded of this, however.

Dennis Ferguson