Subject: Re: Last Call: Inverse Address Resolution Protocol to Draft Standard

From: Don Cochrane <[email-masked]>
Date: Tue, 21 Apr 1998 08:36:40 -0400 (EDT)

It has been my experience with FR DTE Bridge/Router/FRADs that in the
case of ANSI T1-617 Annex D or ITU Q.933 Annex A, the local FR DTE does
not know anything about the far end DLCI without it being 
advertised first or statically entered. Due to this, in my case, I also
back-fill the target hw address with zeros on an initial InARP request. 

On a reply I know the target info from the request (that is as long as 
the InARP received is correct!).

The draft refers to the target hw address as if I always know what it is
before I send out a request packet.

(For details see both the format for an InARP request on page 4, and 
section 7 (Protocol Operation), second paragraph, page 3).

Can this be clarified?
                       ***DC***

The IESG wrote:
> 
> The IESG has received a request from the Internetworking Over NBMA
> Working Group to consider Inverse Address Resolution Protocol
> <draft-ietf-ion-inarp-update-02.txt> as a Draft Standard. This is an update to RFC 1293, currently a Proposed Standard.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by May 5, 1998.
> 
> Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-ion-inarp-update-02.txt
> 
> An implementation Report is available at
> 
>         http://www.ietf.org/IESG/IARP.implementation

--IAA06741.893160551/roc-mail2.ctron.com--

----- End Included Message -----

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 21 Apr 1998 16:36:35 -0400

Don,

I believe what you're looking for is already in
draft-ietf-ion-inarp-update-02.txt.  In section 7 on page 3, it says:

   When an interface supporting InARP becomes active, it should initiate
   the InARP protocol and format InARP requests for each active PVC for
   which InARP is active.  To do this, a requesting station simply
   formats a request by inserting its source hardware, source protocol
   addresses and the known target hardware address.  It then zero fills
   the target protocol address field.  Finally, it will encapsulate the
   packet for the specific network and send it directly to the target
   station.

If you really meant the target hardware address, and not the target
protocol address, you already know that from the Q.933A or T1.617D status
update, which lists the DLCI (aka hardware address) of each PVC on the
interface, along with its status.  No manual configuration is necessary.

Cheers,
Andy

-------

>section 7 (Protocol Operation), second paragraph, page 3).

________________________________________________________________________
Andrew G. Malis  [email-masked]  phone:978 952-7414   fax:978 392-1484
Ascend Communications, Inc.        1 Robbins Road     Westford, MA 01886

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 21 Apr 1998 16:36:35 -0400

Don,

Cheers,
Andy

-------

________________________________________________________________________
Andrew G. Malis  [email-masked]  phone:978 952-7414   fax:978 392-1484
Ascend Communications, Inc.        1 Robbins Road     Westford, MA 01886
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.