Re: The Hole in my proposal

"j.garrett" <jwg@mare.att.com> Mon, 06 February 1995 17:26 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05449; 6 Feb 95 12:26 EST
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa05445; 6 Feb 95 12:26 EST
Received: from gw1.att.com (gw1.att.com [192.20.239.133]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id MAA16090 for <rolc@maelstrom.timeplex.com>; Mon, 6 Feb 1995 12:22:34 -0500
Received: from mare.UUCP by ig1.att.att.com id AA05980; Mon, 6 Feb 95 12:23:38 EST
Message-Id: <9502061723.AA05980@ig1.att.att.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "j.garrett" <jwg@mare.att.com>
Date: 6 Feb 95 12:23:00 -0500
Original-From: mare!jwg (j.garrett)
To: jhalpern@newbridge.com
Cc: curtis@ans.net, rolc@maelstrom.timeplex.com, yakov@watson.ibm.com
Subject: Re: The Hole in my proposal

In message <199502061406.JAA09568@maelstrom.acton.timeplex.com>om>,
yakov@watson.ibm.com writes:

> Joel,
> 
> (a) is already solved in BGP-4 (and in IDRP for IPv6) -- there is an AGGREGATOR
> attribute that provides all the information required by (a).
> 
> To accommodate (b) requires minor extensions to BGP-4 -- a router, when
> it peers with another router, should be able to specify to its peer the
> set of destinations the router is "interested in". This set can be defined
> in terms of Routing Information Filters (aka RIFs). RIFs can be passed
> either at BGP-4 peer establishment time (as a set of optional parameters
> in the OPEN message), or after the peering is established (via UPDATE
> messages). There is a document that Curtis, Kannan Varadhan and myself
> are planning to submit as an Internet Draft this week that describes RIFs,
> and how they are supported in BGP-4 and IDRP.
> 
> Yakov.

Since the aggregation issue is being worked by Yakov et. al., are there
other issues with the Directed ARP approach described in RFC1433?

John Garrett