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

["Dave Thaler" <dthaler@windows.microsoft.com>]

> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]
On
> Behalf Of Juergen Schoenwaelder
> Sent: Friday, October 17, 2003 1:58 AM
> To: Wijnen, Bert (Bert)
> Cc: Mreview (E-mail)
> Subject: Re: FW: draft-ietf-tewg-mib-07.txt
> 
> 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).

I am continuing to push them on this.  So far only Venkata Naidu has
responded, and he is in apparent agreement with my points.  

My understanding so far is that the AS'es are in fact _not_
endpoints.  They are simply criteria used in doing the logical
routing table lookup to decide which tunnel to send across,
rather than being used for encapsulation.  If this is correct,
it indicates that the MIB is not yet ready, although the fix
to the draft is probably not too hard.

I'm still waiting for Kireeti or anyone else to confirm this.
 
> 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. 

Completely agree.

> 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.

Agree.

> > 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.

Agree.  I am happy to provide concrete objects once our questions get
answered so we have enough context.  The one Juergen mentions above
is the biggest one.

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