On Mon, Jun 10, 2002 at 07:43:18AM -0400, Steven M. Bellovin wrote:
> In message <[EMAIL PROTECTED]>, Hiroki Ishibashi writes:
> >Steven M. Bellovin wrote:
> >
>
> >>I'm still confused. If a packet arrives on a site-enabled interface,
> >>addressed to multicast address AllSPFRouters, and with protocol number
> >>89 (OSPF), to which process is it delivered? Does something actually
> >>peek inside the packet to see if it's advertising global or site-local
> >>addresses when making the dispatching decision?
> >
> >"2.4. Explicit support for multiple instances per link" in RFC2740
> >is the one to be used to identify a process (instance) to which packet
> >are delivered. Not necessary to peek into LSAs for the dispatching
> >decision.
> >
>
> I must be missing something; I still don't understand.
>
> Let's look at a simple case, a router with two physical interfaces with
> one attached to the site backbone, and one feeding a departmental LAN.
> I'm perfectly willing to assume multiple logical interfaces on either
> physical interface.
>
> Let's consider the backbone interface. It's going to be seeing two
> types of routing advertisement, site-local and global. When an
> incoming OSPF packet arrives, it's addressed to the same multicast
> address in either case. To which logical interface does it belong?
It looks as if the intended use of this Instance ID is to have multiple
groups of OSPF routers running on the same link, _which know nothing
about each other_. It doesn't look as if it's intended that any
particular router would ever have a given interface assigned more than
one Instance ID.
Mind that said, it would be possible to do this, with one instance
ID for globals and one for site locals, but it would require some
form of receive demultiplexing to deliver the appropriate packets to
the appropriate 'instance' of OSPF running locally. This would obviouly
require peeking into the OSPF header, but not into the LSAs.
e.g. a unix method - have a listener process on protocol 89, it peeks
at the instance ID, and demuxes the packets to the appropriate
local OSPF process. For Tx the OSPF process can send direct to the
interface.
DF
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
