Subject: Non-member submission from [Dave Thaler <[email-masked]>]

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Fri, 14 May 1999 22:04:47 -0700

Ted Brunner		VideoTele.com
			Tektronix
			MS 50-475
[email-masked]	14150 SW Karl Braun
503.627.1317		Beaverton OR 97005	

------- Forwarded Message

From: Dave Thaler <[email-masked]>
To: "'Erik Nordmark'" <[email-masked]>,
        "[email-masked]'"
	 <[email-masked]>
Cc: Bert Wijnen <[email-masked]>,
        Theodore Brunner
	 <[email-masked]>,
        Thomas Narten <[email-masked]>
Subject: RE: draft-ietf-ifmib-tunnel-mib-03.txt
Date: Thu, 13 May 1999 17:43:59 -0700
X-Mailer: Internet Mail Service (5.5.2524.0)

The document which prompted the addition of the
tunnelIfEncapsLimit object in the IP Tunnel MIB was indeed 
RFC 2473 (long before it was an RFC though :).  At that point, 
it wasn't yet determined whether the MIB would be for tunneling 
over IPv6 or not, and there was no theoretical reason why the 
mechanism for IPv6 in RFC 2473 couldn't be used for IPv4 as 
well if someone defines an Encapsulation Limit option for IPv4.

Since no such option exists currently, we could:
a) remove this object from the MIB
b) reference RFC 2473 for the behavior (this doesn't seem right)
c) specify the behavior in the MIB (doesn't seem right either)
d) leave the object there but don't specify the behavior of a
    protocol, leaving it open for a future generic IPv4 option 
    without needing to rev the MIB.

Does anyone else have an opinion on this?

As far as I know, there is no current document other than 
RFC 2473 which mentions an encapsulation limit.

I would prefer (d), but would be open to (a) as a second choice.

- -Dave

> -----Original Message-----
> From:	Erik Nordmark [SMTP:[email-masked]]
> Sent:	Thursday, May 13, 1999 11:34 AM
> To:	Dave Thaler
> Cc:	Erik Nordmark; Bert Wijnen; Theodore Brunner; Thomas Narten
> Subject:	Re: draft-ietf-ifmib-tunnel-mib-03.txt
> 
> > tunnelIfEncapsLimit OBJECT-TYPE
> >     SYNTAX     Integer32
> >     MAX-ACCESS read-write
> >     STATUS     current
> >     DESCRIPTION
> >             "The maximum number of encapsulations permitted for packets
> >             undergoing encapsulation at this node.  A value of 0
> >             indicates that no limit is present (except as a result of
> >             the packet size)."
> >     ::= { tunnelIfEntry 7 }
> 
> Are there tunneling protocols which enforce such a limit?
> (RFC 2473 does for tunneling over IPv6 but this mib is only for tunneling
> over IPv4.)
> 
> If there isn't such a protocol, and given that it is useful to restrict 
> the number of nested encapsulations, I think the above statement needs to
> be more clear on the semantics.
> 
> Using the term "nested encapsulation" would help (used in RFC 2473)
> Also pointing out that in order to determine nested encapsulations the 
> encapsulating node needs to parse the content of the packet.
> 
>    Erik

------- End of Forwarded Message