RE: f/r and ip i/f's
Malis_A <MALIS@corp.timeplex.com> Wed, 26 May 1993 19:47 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13689; 26 May 93 15:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13685; 26 May 93 15:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21523; 26 May 93 15:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13653; 26 May 93 15:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13649; 26 May 93 15:46 EDT
Received: from ccmail.timeplex.com by CNRI.Reston.VA.US id aa21495; 26 May 93 15:46 EDT
Received: from mr.timeplex.com by sys30.timeplex.com (PMDF #2740 ) id <01GYMXD230528WWE5D@sys30.timeplex.com>; Wed, 26 May 1993 15:47:28 EDT
Received: with PMDF-MR; Wed, 26 May 1993 15:47:17 EDT
Date: Wed, 26 May 1993 15:47:21 -0400
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Malis_A <MALIS@corp.timeplex.com>
Subject: RE: f/r and ip i/f's
To: IPLPDN Working Group <iplpdn@CNRI.Reston.VA.US>
Message-id: <01GYMXD1Z93O8WWE5D@mr.timeplex.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Content-transfer-encoding: 7bit
UA-content-id: RE: f/r and ip i/f's
X-Hop-count: 1
A1-type: MAIL
To : IPLPDN Working Group Date: 26-MAY-1993 15:47:21.00 Dave, > Has this exchange revealed some omissions in the > RFC1294 text? i.e., does it clearly say: > - When running IP over a f/r net, it is not necessary that all attached IP > interfaces be configured with addresses within a single IP network/subnet RFC 1294's intention is to standardize encapsulation over FR, not how you set up your IP addressing structure. Using the 1294 encapsulation, you may either treat your FR interface as a NBMA network (with all neighbors on the same IP subnet), or as a collection of virtual leased-line interfaces -- it's your choice. These issues are discussed in detail in draft-ietf-ospf-guidelines-frn-00.txt, which describes how to set up your IP addressing and route over Frame Relay. > - At least one IP subnet is requred on the f/r i/f for IP to route over it. Again, this is strictly a router configuration issue. For example, you could configure a FR PVC as an unnumbered link to another router. In that case, you could certainly router over the interface without having an IP subnet associated with it. These two points are really specific to Fred's implementation rather than generic to all router FR interfaces. > And again in the case of INARP, are the actions Fred recommends clearly > stated? For some implementations, Fred's action isn't required. For example, in Ascom Timeplex's implementation, when the Local Management Interface signals the presence of a PVC, the router uses Inverse ARP to automatically determine the neighbor on the PVC. The neighbors do not have to be preconfigured (unless you explicitly want to preconfigure them). Cheers, Andy ____________________________________________________________________________ Andrew G. Malis malis_a@timeplex.com Ph: +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX:+1 508 264-4999
- f/r and ip i/f's David M. Piscitello
- Re: f/r and ip i/f's Programmer from hell
- RE: f/r and ip i/f's Malis_A
- RE: f/r and ip i/f's Fred Baker