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

RE: Where to define IANAtunnelType TC

On Wed, 1 Sep 2004, Dave Thaler wrote:
> This question was discussed last year on this list and on the IF-MIB
> list (which created the IANAifType-MIB in the first place).
> 
> See http://ops.ietf.org/lists/mreview/mreview.2003/msg00632.html
> which is the approach which is now taken by the tunnel mib.
> 
> (Bert, you were on this thread too:
> http://ops.ietf.org/lists/mreview/mreview.2003/msg00631.html)
> 
> I can't remember who all commented on the if-mib list (the mailing
> list archive seems to be down at the moment).

I have attached the relevant entries from my personal if-mib mailing
list archive.  I can't guarantee that these are all the pertinent
messages that appeared on that list, but they are the ones I had.

In general, I agree with the idea of putting this TC in the
IANAifType-MIB.  I am a little bit busy at the moment but I'll try
to provide more detailed comments in response to Bert's and Dan's
comments in subsequent messages.

Hope this helps,

Mike Heard
--- Begin Message --- 
Forwarding this announcement to the most relevant WG's...

RFC 2667, entitled "IP Tunnel MIB", only supported 
point-to-point tunnels over IPv4.  This draft updates 
RFC 2667 to also support tunnels over IPv6, as well as 
tunnels which aren't just point-to-point (e.g. 6to4).
It also clarifies the use of the ifRcvAddressTable
for all tunnels.

It uses the InetAddress types like the other MIBs
that have been done by the IPv6MIB Design Team.

-Dave

* To: IETF-Announce: ; 
* Subject: I-D ACTION:draft-thaler-inet-tunnel-mib-00.txt 
* From: Internet-Drafts@ietf.org 
* Date: Tue, 14 Oct 2003 15:35:25 -0400 
* Reply-to: Internet-Drafts@ietf.org 
* Sender: owner-ietf-announce@ietf.org 
________________________________________
A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: IP Tunnel MIB
	Author(s)	: D. Thaler
	Filename	: draft-thaler-inet-tunnel-mib-00.txt
	Pages		: 26
	Date		: 2003-10-14
	
This memo defines a Management Information Base (MIB) for use with
network management protocols in the Internet community.  In
particular, it describes managed objects used for managing tunnels
of any type over IPv4 and IPv6 networks.  Extension MIBs may be
designed for managing protocol-specific objects. Likewise,
extension MIBs may be designed for managing security-specific
objects.  This MIB does not support tunnels over non-IP networks.
Management of such tunnels may be supported by other MIBs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-thaler-inet-tunnel-mib-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-thaler-inet-tunnel-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-thaler-inet-tunnel-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-thaler-inet-tunnel-mib-00.txt>



_______________________________________________
ifmib mailing list
ifmib@ietf.org
https://www1.ietf.org/mailman/listinfo/ifmib

--- End Message ---
--- Begin Message --- 
Pekka Savola writes:
> Thanks Dave.
> 
> Two very high-level comments.
> 
> An obvious oversight (or intentional one :-) is that I see an IANA
> registry being created, but no guidance on how new values should be
> added to it (IETF Consensus, Standards Action, FCFS, etc.)

Actually the proposal is that the guidance be identical to that for
ifType values (anything different results in prolonging the incentive
problem that exists today).

I believe ifType is currently first-come-first-serve.

I'll put a summary of this issue shortly in a subsequent email.

> Also, it was not clear which WG you intend to run this through
> officially.  I'm assuming ifmib. (Just trying to figure out what
> will be the role of v6ops WG in this process..)

IFMIB is concluded so that's not an official option (although I still
want any feedback from people on this list :)

As a result, in Minneapolis, the IPv6 WG accepted the document as a WG
document, just like for all the other "core" IP MIBs which don't have an
official home and which are just being updated to be version-agnostic.

-Dave
 

_______________________________________________
ifmib mailing list
ifmib@ietf.org
https://www1.ietf.org/mailman/listinfo/ifmib

--- End Message ---
--- Begin Message --- 

Current state of affairs:
1) the IANAifType-MIB contains the IANAifType TC which has
(at least from my understanding) a first-come-first-serve
assignment policy.
2) the TUNNEL-MIB (RFC 2667) uses ifType = tunnel(131)
and defines a tunnel subtype enum (which was not a TC)
to "point" to specific tunnel types in the same way that
ifType points to specific interface types.  The intent was
that all tunnels over IP use ifType = tunnel(131) and
then use different tunnel subtypes.

As a result, there have been at least one, probably multiple 
cases where IANA has (correctly, as there was no alternative)
assigned ifType values to new tunnel types, and hence some 
of the benefit of the Tunnel MIB is lost.

The Tunnel MIB is now being updated, and we have the opportunity
to fix this, or at least avoid new occurrences of assigning
an ifType where a tunnel subtype is more appropriate.

Looking at the ifType values in question:

1: sixToFour (215), -- 6to4 interface

   Previously the Tunnel MIB only mentioned point-to-point
   tunnels, whereas this is a Non-Broadcast Multi-Access (NBMA)
   tunnel.  In the updated tunnel MIB, the DESCRIPTION clauses
   are updated to clarify how such tunnels are represented.

2: gtp (216), -- GTP (GPRS Tunneling Protocol)

   I'm not that familiar with GTP but it appears to be a normal
   point-to-point tunnel over UDP/IP consistent with the
   Tunnel MIB in RFC 2667.

3: mplsTunnel (150),   -- MPLS Tunnel Virtual Interface

   This one was assigned to draft-ietf-mpls-te-mib-14.txt. It's
   not clear to me whether this is actually a tunnel over IP
   though, so I'm not sure whether it's another example or not.

In summary, the problem was that the tunnel subtypes were not
an IANA registry, and so the natural incentive for folks
creating new tunnel types is to get an ifType value instead
of a tunnel subtype value, since the latter required rev'ing
the RFC.

To fix this, the Tunnel MIB update creates a TC and delegates 
it to IANA.  This is straightforward.

However, to completely fix the incentive problem, it needs to be
exactly as easy/difficult to get a tunnel subtype as it is to 
get an ifType.  Simply creating another IANA registry won't
necessarily cause folks to notice it, and/or request one
instead of an ifType where a tunnel subtype is more appropriate.

A proposal in the appendix of draft-thaler-inet-tunnel-mib-00.txt
is to add the IANAtunnelType TC *into the IANAifType-MIB itself* 
alongside the IANAifType TC.  The rationale behind this is that
it makes it easy to find both (you can't claim you didn't know
tunnelType existed when you apply for an ifType) and means a
paragraph of guidelines for when to ask for ifType vs tunnelType
is in one place rather that two separate places with 
cross-references, etc.

I'd like to get feedback on this proposal from IANA and/or the
IF-MIB WG.  This is the only open issue on the document, and
I expect the document to be able to go to last call after this
question is resolved.

-Dave 


_______________________________________________
ifmib mailing list
ifmib@ietf.org
https://www1.ietf.org/mailman/listinfo/ifmib

--- End Message ---
--- Begin Message --- 
On Thu, Dec 04, 2003 at 03:05:21PM -0800, Dave Thaler wrote:

[...]
 
> A proposal in the appendix of draft-thaler-inet-tunnel-mib-00.txt
> is to add the IANAtunnelType TC *into the IANAifType-MIB itself* 
> alongside the IANAifType TC.  The rationale behind this is that
> it makes it easy to find both (you can't claim you didn't know
> tunnelType existed when you apply for an ifType) and means a
> paragraph of guidelines for when to ask for ifType vs tunnelType
> is in one place rather that two separate places with 
> cross-references, etc.

I think the root of the problem is that the IANA maintained interface
type TC is a rather uncontrolled place. Creating another uncontrolled
place next to it (regardless how close it is) is not going to fix this
nor will it make sure that the new TC gets only reasonable assignments.

I think there should be an Expert Review (see RFC 2434) before these
TCs can be updated and perhaps an expert can also be found to go
through the existing assignments and mark those assignments as 
deprecated which are known to be problematic.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
ifmib mailing list
ifmib@ietf.org
https://www1.ietf.org/mailman/listinfo/ifmib

--- End Message ---
--- Begin Message --- 
On Thu, 4 Dec 2003, Dave Thaler wrote:
DT> A proposal in the appendix of draft-thaler-inet-tunnel-mib-00.txt
DT> is to add the IANAtunnelType TC *into the IANAifType-MIB itself*
DT> alongside the IANAifType TC.  The rationale behind this is that
DT> it makes it easy to find both (you can't claim you didn't know
DT> tunnelType existed when you apply for an ifType) and means a
DT> paragraph of guidelines for when to ask for ifType vs tunnelType
DT> is in one place rather that two separate places with
DT> cross-references, etc.
DT> 
DT> I'd like to get feedback on this proposal from IANA and/or the
DT> IF-MIB WG.  This is the only open issue on the document, and
DT> I expect the document to be able to go to last call after this
DT> question is resolved.

I have looked at this proposal and I think it is a good idea. I do
have a few small procedural suggestions, however:

- Rework Section 5, IANA Considerations, to state that the document
introduces a new IANA-maintained TC to be added to the
IANAifType-MIB and that the initial version of the TC is in Appendix
A.  Also state explicitly that the policy for assigning new values
is first-come-first-serve, as defined in RFC 2434, just as is it is
for new ifType values.

- Include only the TC itself in Appendix A, and remove the RFC
Editor note that the section will be removed upon publication.  You
may recall that there was extensive discussion on the mreview list
some time ago about this subject and that there was an IESG ruling
that the initial version of an IANA-maintained MIB module is to to
be published in a non-normative section of the document that defines
a new namespace;  see Section 3.7 of the MIB review guidelines draft
<draft-ietf-ops-mib-review-guidelines-02.txt> for more details.
Even though you won't be creating a new MIB module I think that
including the first version of the new TC in the published RFC
would be in keeping with the spirit of this ruling.

On Fri, 5 Dec 2003, Juergen Schoenwaelder wrote:
JS> I think the root of the problem is that the IANA maintained
JS> interface type TC is a rather uncontrolled place. Creating
JS> another uncontrolled place next to it (regardless how close it
JS> is) is not going to fix this nor will it make sure that the new
JS> TC gets only reasonable assignments.
JS> 
JS> I think there should be an Expert Review (see RFC 2434) before
JS> these TCs can be updated and perhaps an expert can also be found
JS> to go through the existing assignments and mark those
JS> assignments as deprecated which are known to be problematic.

While that may be a reasonable idea, changing from the grandfathered
first-come-first-serve assignment rules for IANAifType TC values is
a separate project from updating the tunnel MIB and placing tunnel
types under IANA maintenance.  It would require an explicit update
to the IANA considerations for the IANAifType-MIB, which should go
in a separate document with its own Last Call.  And I'm not sure
that it's really an urgent priority.  Anything that's done for an
IETF MIB module gets expert review anyway (that's what MIB doctors
are for), and the damage done by unwis allocation requests from
outsiders is pretty limited, I think.

Mike


_______________________________________________
ifmib mailing list
ifmib@ietf.org
https://www1.ietf.org/mailman/listinfo/ifmib

--- End Message ---
--- Begin Message --- 
 
> > A proposal in the appendix of draft-thaler-inet-tunnel-mib-00.txt
> > is to add the IANAtunnelType TC *into the IANAifType-MIB itself* 
> > alongside the IANAifType TC.  The rationale behind this is that
> > it makes it easy to find both (you can't claim you didn't know
> > tunnelType existed when you apply for an ifType) and means a
> > paragraph of guidelines for when to ask for ifType vs tunnelType
> > is in one place rather that two separate places with 
> > cross-references, etc.
> 
> I think the root of the problem is that the IANA maintained interface
> type TC is a rather uncontrolled place. Creating another uncontrolled
> place next to it (regardless how close it is) is not going to fix this
> nor will it make sure that the new TC gets only reasonable 
> assignments.
> 
> I think there should be an Expert Review (see RFC 2434) before these
> TCs can be updated and perhaps an expert can also be found to go
> through the existing assignments and mark those assignments as 
> deprecated which are known to be problematic.
> 
IANA already (often, but maybe not always) asks Keith McKloghrie and myself
for review of not-so-clear cases. Did/do you see trouble in recent assignments?

I do not know what has happened several years back.

And further: are you volunteering as additional expert?

Bert
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 

_______________________________________________
ifmib mailing list
ifmib@ietf.org
https://www1.ietf.org/mailman/listinfo/ifmib

--- End Message ---