Re: FW: draft-ietf-tewg-mib-07.txt

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

On Thu, Oct 16, 2003 at 08:49:43PM +0200, Wijnen, Bert (Bert) wrote:

> I sort of was left with the impression that they (specifically Kireeti)
> had convinced you (us) that they needed ASes and unnumbered and such as
> addresses, and so I steered them to define their TeHopAddress(Type) TCs.

They could not convince me to add AS numbers to the InetAddress TCs,
which was the primary reason why I was involved at that time. But they 
also could not explain to me how a tunnel between ASes can be setup by 
just setting teTunnelSourceAddress and teTunnelDestinationAddress to 
an AS number. The discussion stopped because they felt that I do not
understand (which might perfectly be the case since I am not in the
traffic engineering business) and I did not push hard enough to make
them explain this to me (which is entirely my fault). 

But this is a general problem - you sometimes see something that looks
really strange and where it becomes obvious that resolving the issue
requires quite some discussion to develop a better understanding of
the issue on both sides. How can we make sure that such discussions
are not deferred until the very last minute? Perhaps I should have
talked to the responsible WG chair and AD to make them aware that 
there is a potential problem lurking around which needs attention,
even though I did not have the time / energy at that moment to 
resolve the issue.

> I need to know if this is bad anuf to say "over my dead body" or
> if we can approve this (let it go) now on stds track.
> Or if that is too much, let it go as Informational or Experimental.
> If the former, we can try to work a more ideal solution (soon)
> ourselves and present that to those groups.

Well, I fail to see how one can create a tunnel by specifying the two
tunnel endpoints by AS numbers. It looks like the idea is that the
creating of such a row causes some magic to happen and finally leads
to the execution of a signaling protocol which than might cause entries
in device specific MIBs. So this is really a MIB for managing traffic
engineering managers rather than devices. As a technical nit, please
note that teSignalingProto has an enumeration rsvpte(1) and crldp(2)
with appropriate references in the REFERENCE clause but the references
in the references section are listed under informative.

This is my _interpretation_ of what I believe the MIB does and how it
relates to other MIBs. This is not what the text in section 3.5 tries
to tell me - so I am indeed reading between the lines and I think that
should be fixed. Perhaps a figure how these things play together and 
what actually happens if you create a tunnel between two ASes using 
this MIB will help others as well to understand how this is supposed 
to work. This is a technical question about understanding the MIB
and it does not matter much to me how the IESG classifies the RFC 
document. 

> If the latter case I would say that we MUST commit to RSN define
> the proper MIB objects and present/defend them to those people.

What is required is to have a constructive dialog what this MIB is
actually trying to achieve and how this relates to what we generally
do in IETF MIB modules. There is indeed a high probability that I 
completely misunderstand what the MIB is trying to achieve. But Dave 
seemed to raise similar questions so I guess this needs to be worked 
out together with the TE folks - you can not expect that we provide 
concrete objects since at least I do not really understand how this 
is supposed to work. 

/js

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