OSPFv3: Source/dest IP address for virtual link

Mike Fox <mjfox@US.IBM.COM> Thu, 19 June 2003 14:56 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22834 for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Jun 2003 10:56:53 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM ( by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A20C02@cherry.ease.lsoft.com>; Thu, 19 Jun 2003 10:56:53 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45948503 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 Jun 2003 10:56:51 -0400
Received: from by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 19 Jun 2003 10:56:51 -0400
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com []) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5JEunkj272462 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 Jun 2003 10:56:49 -0400
Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com []) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5JEulVd081326 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 Jun 2003 08:56:47 -0600
X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002
X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/19/2003 08:56:47
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Message-ID: <OF8137A05F.EAF3357A-ON85256D4A.00505505-85256D4A.0051BC34@us.ibm.com>
Date: Thu, 19 Jun 2003 10:56:44 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mike Fox <mjfox@US.IBM.COM>
Subject: OSPFv3: Source/dest IP address for virtual link
Precedence: list

The OSPFv3 RFC says to use the first address with the LA-bit set from a
host's set of intra-area prefix LSAs as the destination address of a
virtual link.
Also, draft-ietf-ospf-ospfv3-auth-01.txt says that for the source address a
host should use its own first address with the LA-bit set from its
intra-area prefix LSAs.

With hosts possibly originating multiple intra-area prefix LSAs, what's the
mechanism for choosing which intra-area prefix LSA is first?  We are
thinking of using the one from the host with the lowest LSID,and if an
eligible address is not found, continuing the search at the next-highest
LSID, etc.   We would do the same in picking our virtual link source

But even this has problems.  There's no guarantee that LSAs will arrive in
any order, even if they were sent out consecutively.  Supposed a host with
a virtual link sends an intra-area prefix LSA with LSID of 1, the virtual
link neighbor picks the first LA-bit address out of it, then one arrives
with an LSID of 0 that also has an eligible address in it?    Does the
virtual link get torn down and then rebuilt with the new address?

Also, what about when addresses disappear because of renumbering or are
simply removed?  Suppose we choose address A as the virtual link
destination and then at a later time address A is removed from the LSA

We are considering requiring our customers to configure  source addresses
for  virtual links.  We would then advertise that address in an intra-area
prefix LSA whose LSID is 0.

Enterprise Network Solutions
Research Triangle Park, NC  USA