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 [209.119.0.109]) 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 (209.119.0.19) 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 32.97.110.131 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 [9.17.193.32]) 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 [9.17.193.82]) 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
To: OSPF@PEACH.EASE.LSOFT.COM
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 address. 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 database? 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. Mike ----------------------------------------------------------------------- Enterprise Network Solutions ----------------------------------------------------------------------- Research Triangle Park, NC USA