The MPLS WG Archive

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Thanks,
Bert 

-----Original Message-----
From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
Sent: zondag 14 september 2003 0:26
To: Wijnen, Bert (Bert); dubuc.consulting@rogers.com; tnadeau@cisco.com;
sudheer@ieee.org; jplang@ieee.org
Cc: Loa Andersson (E-mail); Alex Zinin (E-mail)
Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt


Yes to both.

-Dave

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Saturday, September 13, 2003 1:21 PM
> To: Dave Thaler; Wijnen, Bert (Bert); dubuc.consulting@rogers.com;
> tnadeau@cisco.com; sudheer@ieee.org; jplang@ieee.org
> Cc: Loa Andersson (E-mail); Alex Zinin (E-mail)
> Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt
> 
> Thanks dave. I think that in the first sentence you also meant
>  draft-ietf-mpls-telink-mib-04.txt.
> 
> I hope it is OK with you to post this to MPLS WG as well?
> 
> Thanks,
> Bert
> 
> > -----Original Message-----
> > From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
> > Sent: zaterdag 13 september 2003 22:17
> > To: Wijnen, Bert (Bert); dubuc.consulting@rogers.com;
> > tnadeau@cisco.com;
> > sudheer@ieee.org; jplang@ieee.org
> > Subject: DT's review of draft-ietf-mpls-telink-mib-04.txt
> >
> >
> > I've completed a review of draft-ietf-tewg-mib-06.txt at
> > Bert's request,
> > concentrating on the relationships with the Interfaces MIB and the
> > IPv4 Tunnel MIB.
> >
> > Relationship with IF-MIB:
> >
> >  This is in pretty good shape.  Section 8 meets most of the
> > requiements
> >  outlined in section 4 of RFC 2863.  The only requirements not met
> > appear
> >  to be the ones regarding ifRcvAddressTable and the
> > conditions (if any)
> >  relating to ifXxxOctets with respect to frames with errors.
> >
> > Relationship with IPv4 Tunnel MIB:
> >
> >  This MIB has no text on the relationship with the IPv4
> > Tunnel MIB, and
> >  does not explain why it does not extend that MIB.  Of course this
> >  document is not IPv4-specific, but we know we need a
> > corresponding IPv6
> >
> >  Tunnel MIB (or perhaps a generic IP Tunnel MIB) anyway.
> > Given that, it
> >
> >  is unclear whether there is sufficient justification
> > (certainly none in
> >
> >  the draft) to not extend it/them.
> >
> >  The argument to extend it/them is twofold:
> >  a) you are consistent with other tunnel management schemes,
> > rather than
> >     confusing people with multiple conflicting schemes, and
> >  b) that you get a number of things currently missing, specifically:
> >     tunnelIfHopLimit, tunnelIfSecurity, tunnelConfigEncapsMethod,
> >     tunnelIfTOS, and the ability to look up a tunnel index by its
> >     endpoints.
> >
> >  teLinkRowStatus - redundant with tunnelConfigStatus?
> >
> >  The real issue is how to handle the teLinkLocalIpAddr and
> >  teLinkRemoteIpAddr.  The 'numbered' and 'unnumbered' link
terminology
> >  appears to come from [GMPLS-ARCH], but from a quick glance at that
> >  document, is is unclear whether the IP addresses are those used for
> >  encapsulation (i.e. like MAC addresses from the point of view of
the
> >  teLink interface), or those assigned to the inside.  I'm assuming
the
> >  former, since the latter would definitely be redundant with the
inet
> >  address table like on any other interface.
> >
> >  So there are currently three cases, as I understand it:
> >  1) it's tunneling using IPv4 addresses.  In this case I see no
reason
> >     to not extend the IPv4 Tunnel MIB.  teLinkLocalIpAddr
> >     and teLinkRemoteIpAddr are redundant with tunnelIfLocalAddress
and
> >     tunnelIfRemoteAddress, respectively.
> >  2) it's tunneling using IPv6 addresses.  In this case it can
> >     extend an IPv6 Tunnel MIB (or perhaps an Inet Tunnel MIB).
> >     teLinkLocalIpAddr and teLinkRemoteIpAddr would be redundant with
> >     objects in that MIB.
> >  3) it's not tunneling using either one.  In this case
> >     teLinkLocalIpAddr and teLinkRemoteIpAddr are empty.
> >
> > Hence, I'd propose the following actions:
> >  1) this document remove the teLinkLocalIpAddr and
teLinkRemoteIpAddr
> >     objects (leaving teLinkAddressType is fine).
> >  2) we (the OPS area) write the IPv6 or Inet Tunnel MIB asap.
> >     I had volunteered for this but it was lower priority.  If
> > this MIB
> >     takes a dependency on it, I think it could be done fairly
quickly
> >     since it's just adapting the existing RFC 2667.
> >     In that document we define a new tunnelIfEncapsMethod for MPLS.
> >  3) If the unnumbered case does not do tunneling over IP, then an
> >     ifType of teLink(200) could identify this case (only).
> >     Numbered links would use an ifType of tunnel, with an encaps
> >     method of mpls.  This would give the benefits of using the
tunnel
> > mib.
> >
> > -Dave
> >
> >