[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IF types durring review of EPON-04



Sorry if I wasn't clear, both the single physical interface and the N
virtual logical interfaces should use ifType ethernetCsmacd (6).

The ifType maps to a media-specific MIB (by convention, for standards
track MIBs, Iftype XXX means the MIB is transmission.XXX).  Hence the
choice of ifType is determined by what media-specific MIB is intended to
apply.

From page 13 of EPON-04:
   At the OLT there is a single physical interface and N virtual logical
   interfaces for the virtual links of the ONUs ( and another virtual
   interface for the broadcast virtual link).  As can be seen from the
   layering diagram above, the MAC is virtually duplicated and therefore
   the selection for the management for this scenario is to allocate an
   interface index for each one of the virtual link and an additional
   interface index for the OLT.  Therefore the Interface, MAU and
   etherLike interfaces MIBs have a row (ifIndex) for each virtual link
   at the OLT.  The justification for this partition is that the
   interfaces are quite well separated as they present physical
   different ONUs which are viewed from the OLT point of view, and for
   instance there is a meaning for a separate bad frames, or bad octets
   counters for each virtual link as the ONUs can be distanced
   differently, which is quite similar to a separate physical interface.

From this it is clear that the intent is that both the physical
interface and the virtual interfaces are intended to use the
Ethernet-like Interfaces MIB (RFC3635) as the media-specific module.
Their rationale is that the same counters are interesting both from a
physical interface (aggregate) perspective as well as from a per-virtual
link perspective.  This is fine and mirrors what RFC 3371 did with
multilink PPP.

This is what I meant by the layering model is fine.

On the topic of making additional documentation available, it would be
helpful to have a table online somewhere (either at IANA or at
ops.ietf.org) that mapped from ifType to the media-specific MIB module.
With a little bit of work, one could come up with the start of such a
table by looking through
http://www.icir.org/fenner/mibs/mib-index.html  
Maybe I'll go ahead and do this and send the results out in email for
review...

-Dave

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Saturday, May 20, 2006 2:05 PM
> To: Dave Thaler
> Cc: mreview@ops.ietf.org
> Subject: RE: IF types durring review of EPON-04
> 
> HI,
> 
> Thank you for the comments below. In my original message,
> I was asking for ifType for the virtual interfaces. What
> value do you think they should use, and why?
> 
> Regards,
> /david t. perkins
> 
> On Fri, 19 May 2006, Dave Thaler wrote:
> > Ok, I've looked through EPON-04 with respect to the relationship to
the
> > interfaces MIB and the Ethernet mib.  (I also saw lots of typos and
> > grammatical errors in EPON-04, so someone should probably go through
it
> > for those.  It also has lots of acronyms which are not expanded on
first
> > use.)
> >
> > The key sentence in EPON-04 is in section 3.1:
> > >  Implementing this module therefore MUST require implementation of
> > >  Interfaces MIB module [RFC2863] and Ethernet-like Interfaces MIB
> > >  module [RFC3635].
> >
> > This is fine, since throughout the doc it says that EPON interfaces
are
> > Ethernet-like interfaces and they don't want to duplicate all the
> > objects in that MIB.
> >
> > However, the problem is it uses gigabitEthernet(117).
> >
> > Section 3.2.4 of RFC 3635 (which, as quoted above, is a MUST for
EPON
> > interfaces) says:
> > >  It is REQUIRED that all ethernet-like interfaces
> > >  use an ifType of ethernetCsmacd(6) regardless of the speed that
the
> > >  interface is running or the link-layer encapsulation in use.
> > and
> > >  A requirement for
> > >  compliance with this document is that all ethernet-like
interfaces
> > >  MUST return ethernetCsmacd(6) for ifType, and MUST NOT return
> > >  fastEther(62), fastEtherFX(69), or gigabitEthernet(117).
> >
> > It's pretty clear from the above that the only legal value for use
in
> > EPON is ethernetCsmacd(6).
> >
> > Similarly, the ianaiftype-mib says:
> > >  gigabitEthernet (117), -- Obsoleted via
> > RFC-draft-ietf-hubmib-etherif-mib-v3  ethernetCsmacd (6) should be
used
> > instead
> >
> > (Yes the reference in the comment is stale... per
> >
http://www.ietf.org/internet-drafts/draft-ietf-hubmib-etherif-mib-v3-03.
> > txt it is the same as RFC 3635 quoted above.)
> >
> > The layering model described on page 13 (of using one Ethernet-like
> > interface that is stacked on top of a set of other Ethernet-like
> > interaces) is fine.  This is equivalent to what RFC 3371 (the L2TP
MIB)
> > does for multilink PPP for similar reasons.
> >
> > Since EPON is not defining a new ifType, the other requirements in
RFC
> > 2863 don't apply to it as they are met by RFC 3635.
> >
> > -Dave
> >
> > > -----Original Message-----
> > > From: owner-mreview@ops.ietf.org
[mailto:owner-mreview@ops.ietf.org]
> > On
> > > Behalf Of Dave Thaler
> > > Sent: Friday, May 12, 2006 10:49 AM
> > > To: David T. Perkins; mreview@ops.ietf.org
> > > Subject: RE: IF types durring review of EPON-04
> > >
> > > I've been doing the reviews of relationships to the Interfaces
MIB, so
> > > I can do this, but I'm swamped right now.  I could probably get to
> > this
> > > by end of next week (5/19) if someone else doesn't get to it
before
> > > then.
> > >
> > > -Dave
> > >
> > > -----Original Message-----
> > > From: owner-mreview@ops.ietf.org
[mailto:owner-mreview@ops.ietf.org]
> > On
> > > Behalf Of David T. Perkins
> > > Sent: Friday, May 12, 2006 10:25 AM
> > > To: mreview@ops.ietf.org
> > > Subject: IF types durring review of EPON-04
> > >
> > > HI,
> > >
> > > I'm doing a second review of EPON-04 I-D, which is
> > >
> >
http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-epon-mib-04.tx
> > > t
> > >
> > > It is very complex and the previous review raised many questions.
> > > The good news is that it is MUCH better, and it is finally to the
> > > level that someone can make sense of it. However, given that
> > > it is an interface MIB module, there are many additional
> > > considerations that must be followed. I don't remember all of
> > > them, and would need to refresh myself with these considerations
> > > to do a complete job. Is there anyone that can do a scan
> > > after I finish the first pass?
> > >
> > > One question that I have so far is what interface type
> > > to use for the virtual links. The document uses the
> > > same value as the physical (which is gigabitEthernet(117)),
> > > but it seems to me that the propVirtual(53) is more
> > > appropriate.
> > >
> > > In trying to determine the value for ifType, I looked at
> > > http://www.iana.org/assignments/ianaiftype-mib
> > > In it I see that there are 234 types defined.
> > > This seems like an extremely large number. Also,
> > > there is not a reference for each assigned value.
> > > Thus, I could not figure out from looking at
> > > these values what values the should be used
> > > in the EPON MIB module. This seems like a generic
> > > problem that anyone implementing object ifType
> > > would encounter. And a delemma for anyone creating
> > > a new interface MIB module.
> > >
> > > Are there any suggestions that would help me
> > > now with the EPON MIB module, and for making it
> > > easier for future interface MIB module developers?
> > >
> > > Regards,
> > > /david t. perkins
> > >
> > >
> > >
> > >
> >
> >
> >
>