A Traffic Engineering (TE) MIB
draft-ietf-tewg-mib-08

[Note]: 'Back on agenda to ensure we get Haralds and Allisons issues resolved. Participant in PROTO Team pilot:
Workgroup Chair Followup of AD Evaluation Comments
http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-00.txt' added by Amy Vezza

[Note]: 'Back on agenda to ensure we get Haralds and Allisons issues resolved.

Participant in PROTO Team pilot:
Workgroup Chair Followup of AD Evaluation Comments
http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-00.txt' added by Bert Wijnen

Checking with Harald if a new RFC-Editor note can clear his discuss.

Checking with Allison, the log shows she had a DISCUSS recorded (Jun 10th),
but I do not see the actual DISCUSS text. Form the telechat, I have this recollection of her issue:

  Allison was not sure this was just "traffic engineering" related
  tunnels or possibly more generic tunnels.

[Ballot discuss]
This is an "I don't understand" discuss.

Spencer noted in his review:

1. Introduction

  As it stands, this MIB module can only be used to configure or
  monitor a TE Tunnel at its ingress.  The extension of this module for
  use at other points of a Tunnel is for further study.

Spencer: this seems like a pretty significant limitation. Is the idea
that you configure a TE tunnel at its ingress, and the tunnel ingress
router configures the rest of the tunnel routers using some other
mechanism not specified here? or that a management system configures
all of the tunnel routers using some other mechanism not specified
here? I guess what I'm asking is, is this document worth standardizing
with the restriction as stated?

HTA: If the Deeper Meaning is that you configure the headend router for the tunnel, and the router then uses some other mechanism to get the tunnel set up through all the other routers on the path, this is probably OK. But being sure that this is so would be nice.

[Ballot discuss]
This is an "I don't understand" discuss.

Spencer noted in his review:

1. Introduction

  As it stands, this MIB module can only be used to configure or
  monitor a TE Tunnel at its ingress.  The extension of this module for
  use at other points of a Tunnel is for further study.

Spencer: this seems like a pretty significant limitation. Is the idea
that you configure a TE tunnel at its ingress, and the tunnel ingress
router configures the rest of the tunnel routers using some other
mechanism not specified here? or that a management system configures
all of the tunnel routers using some other mechanism not specified
here? I guess what I'm asking is, is this document worth standardizing
with the restriction as stated?

IANA Last Call Comments
Upon approval of this document the IANA will assign a
mib-2 number for teMIB in the following registry:


We understand this to be the only IANA action for
this document.

AD review did not result in showstoppers, so IETF Last Call is requested.

AD Review did show some ID-nits (ID-Checlist) violations and those have been reported to WG chairs.
They can be addressed after IETF Last Call.

WG Last call generated some comments.
Specific issues w.r.t the question of
- do/should we extend the ifmib
- do/should we extend the tunnelmib

Had a discussion with Kireeti and Dave Thaler;
resolution is to add clarifying text.