Re: Proposed changes to Draft Frame Relay MIB for multiprotocol support.
Alan Bartky <alan@xylan.com> Thu, 04 January 1996 23:12 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23641;
4 Jan 96 18:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23637;
4 Jan 96 18:12 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17145;
4 Jan 96 18:12 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23625;
4 Jan 96 18:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23621;
4 Jan 96 18:11 EST
Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa17135;
4 Jan 96 18:11 EST
Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0))
id AA18139; Thu, 4 Jan 96 15:11:14 PST
Received: from canary.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1))
id AA29880; Thu, 4 Jan 96 15:11:10 PST
Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1)
id AA08798; Thu, 4 Jan 96 14:27:20 PST
Date: Thu, 4 Jan 96 14:27:20 PST
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Alan Bartky <alan@xylan.com>
Message-Id: <9601042227.AA08798@irvine.XYLAN.COM>
To: malis@nexen.com
Subject: Re: Proposed changes to Draft Frame Relay MIB for multiprotocol
support.
Cc: iplpdn@CNRI.Reston.VA.US, alan@xylan.com
Andy - My responses are edited in below: >... > >Second for the more difficult one. > >... > >Table Entry 1: ifIndex.10, DLCI 40 > >Table Entry 2: ifIndex.10, DLCI 41 > >Table Entry 3: ifIndex.11, DLCI 40 > >Table Entry 4: ifIndex.11, DLCI 41 > >Table Entry 5: ifIndex.12, DLCI 41 > >Table Entry 6: ifIndex.12, DLCI 42 > > Sounds like in this case, you're not modeling the FR interface as a > multiaccess interface, but as a collection of virtual point-point > interfaces, one for each DLC. If you then give each virtual interface > (DLC) its own ifIndex, you can do the mapping in the ifStack table, right? > My intent in suggesting a change is that it looks like the current draft MIB is attempting to perform the grouping function of virtual circuits as is necessary for RFC 1490 for bridging and routing functions. The ifStack table does not specifically perform this function as it only points between logical layers and does cannot perform the internal mapping/grouping of DLCIs to a "virtual port" that a bridge or router can use. As you know, in frame relay it is often necessary (or at least desirable) to group DLCIs together. The current draft MIB currently has a new object for as follows: frCircuitLogicalIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-write STATUS current DESCRIPTION "Normally the same value as frDlcmiIfIndex, but different when an implementation associates a virtual ifEntry with a DLC or set of DLCs in order to associate higher layer objects such as the ipAddrEntry with a subset of the virtual circuits on a Frame Relay interface. The type of such ifEntries is defined by the higher layer object; for example, if PPP/Frame Relay is implemented, the ifType of this ifEntry would be PPP. If it is not so defined, as would be the case with an ipAddrEntry, it should be of type Other." ::= { frCircuitEntry 20 } This object allows grouping of one or more virtual circuits into a logical interface available for upper layer protocols. The problem as I see it is since it is the virtual circuit table specifying a single upper layer ifIndex, it does not allow any "overlap" of the grouping. In the example in the current draft it shows IP using an ifIndex of 2 and then using the DLCI as an physical address field. The only time IP would need a LogicalIfIndex other than the one defined for the port was if there was a layer between IP and Frame Relay (again as shown in the diagram). The text of the description talks about PPP over Frame Relay where IP actually connects to PPP which happens to run over its own DLCI (I also think the example is not very good since it shows PPP over Frame Relay which has never gotten much support and also goes against RFC 1490 which uses direct IP encapsulation over Frame Relay). My main concern was that a RFC1490 based bridge/router has to support IP, IPX, and Bridging and probably other protocols in the future. Up until now there has been no way in the standard MIBs to have DLCI grouping and I am concerned about having a single upward pointer for logical interfaces from per virtual circuit table entry. It would be nice to have a standard method of grouping DLCIs (for example to support DLCIs grouped together for bridging applications) that had the potential of more than one Logical Interface Index per DLCI. The text I submitted was a first stab proposal in order to try an accomplish this (I am willing to listen for alternate proposals, and to see if this affects anyone else). >... > > > Andy > > __________________________________________________________________________ > Andrew G. Malis Ascom Nexion voice: +1 508 266-4522 > malis@nexen.com 289 Great Rd., Acton MA 01720 USA FAX: +1 508 266-2300 > Regards, Alan ********************************************************** Alan K. Bartky Email:alan@xylan.com Principal Software Engineer XYLAN Corporation Voice:(714) 597-8042 15707 ROCKFIELD BLVD STE 155F FAX: (714) 597-8342 IRVINE CA 92718-2830 **********************************************************
- Proposed changes to Draft Frame Relay MIB for mul… Alan Bartky
- Re: Proposed changes to Draft Frame Relay MIB for… James Watt
- Re: Proposed changes to Draft Frame Relay MIB for… Andrew G. Malis
- Re: Proposed changes to Draft Frame Relay MIB for… Alan Bartky
- Re: Proposed changes to Draft Frame Relay MIB for… Alan Bartky
- Re: Proposed changes to Draft Frame Relay MIB for… James Watt