[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    RE: Questions about draft-ietf-ipv6-inet-tunnel-mib-02.txt
From:       "Dave Thaler" <dthaler () windows ! microsoft ! com>
Date:       2004-08-25 0:43:23
Message-ID: C9588551DE135A41AA2626CB645309370AC877CE () WIN-MSG-10 ! wingroup ! windeploy ! ntdev ! microsoft ! com
[Download RAW message or body]


> -----Original Message-----
> From: Ville Nuorvala [mailto:vnuorval@tcs.hut.fi]
> Sent: Monday, August 23, 2004 2:08 AM
> To: Dave Thaler
> 
> Hi Dave,
> 
> I just skimmed through your draft prompted by the the IESG last call
> message sent to the IPv6 WG list.
> 
> Having worked with IPv6-in-IPv6 tunnels, I was looking at your draft
from
> the IPv6 point of view. There seem to be MIB entries for TOS,
FlowLabel,
> Hop Limit and such, but the Tunnel Encapsulation Limit defined in RFC
2473
> is missing. Is this intentional? I was also surprised not to see the
afore
> mentioned RFC being mentioned as a reference.

I don't think it's been explicitly discussed, so I don't think it's
intentional.  Some history...

The following was present in I-D's prior to RFC 2667 up to 
draft-ietf-ifmib-tunnel-mib-04.txt (which you can find with
a web search):

tunnelIfEncapsLimit OBJECT-TYPE
    SYNTAX     Integer32
    MAX-ACCESS read-create
    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 }

However, it was removed before publication as an RFC, since 
RFC 2667 was IPv4-specific, and (as far as we knew) no such
limit exists for IPv4.

When converting the MIB to be version-agnostic, it was not added back
in (but could be).  RFC 2473 is a bit vague though on whether this
is a per-node or a per-tunnel limit.  

Question to tunnel implementers:
1) Do you support the Tunnel Encapsulation Limit?
2) If so, is it configurable per tunnel?

Assuming there are implementations, I am happy to add this back in
(probably as per-interface, like it was before), although to be 
more consistent with what goes into the Dest Option, I'd change the 
range to be (-1 | 0..255) where -1 means just limited by MTU and
0..255 is the value placed in the option, i.e.:

tunnelIfEncapsLimit OBJECT-TYPE
    SYNTAX     Integer32 (-1 | 0..255)
    MAX-ACCESS read-create
    STATUS     current
    DESCRIPTION
            "The maximum number of additional encapsulations permitted
            for packets undergoing encapsulation at this node.  A value
            of -1 indicates that no limit is present (except as a result
            of the packet size)."
    REFERENCE  "RFC 2473, section 4.1.1"
    ::= { tunnelIfEntry 11 }

-Dave


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]