Re: Proposed changes to Draft Frame Relay MIB for multiprotocol support.

[Alan Bartky <[e-mail]>]

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: [phone]
> [e-mail]   289 Great Rd., Acton MA 01720 USA   FAX: [phone]
>

Regards,

Alan

**********************************************************
Alan K. Bartky                       Email:[e-mail]
Principal Software Engineer
XYLAN Corporation                    Voice:[phone]
15707 ROCKFIELD BLVD STE 155F        FAX:  [phone]
IRVINE CA 92718-2830
**********************************************************