[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: path taken by a packet feedback



 The draft that I read is at
 http://www.ietf.org/internet-drafts/draft-ietf-tewg-mib-03.txt
 dated Septembre 2002, expire March 2003. Is that the one you mentionned?.

 I have another question about tunnel. As the MIB, how many tunnel may have
between to node.
 -  If only one. In that case, sourse and destination nodes adresses re the
key attribute of teTunnelEntry, which identify the teTunnelEntry?.
 - If there are many tunnels, what are the different between tunnels. What
is the semantic indentification of this tunnel, surely that we have an
identification tunnelIndex or tunnelName but it does not signifies a
pacticular caracter of a tunnel.

>
>
> > > I have some questions about the new draft of the group
> >
> > This "new" draft is over 2 years old, so instead of calling it 'new',
> > might I suggest 'toddler'?
> >
> > > 1- A tunnel connect two network nodes (for exemple A and B) consists
of
> =
> > > severals paths, they are diffirents in bandwith, in classe of
resources
> =
> > > included and excluded, and each has its hops. When a packet is sent
from
> =
> > > a node (A) to other (B), the packet will take a path of the tunnel. =
> > > Which information in the MIB can tell us which path is currently took
=
> > > (that means the packet took).
> >
> > A path has a status --
> >
> >            "The operational status of the path:
> >                 unknown:
> >                 down:        signaling failed
> >                 testing:     administratively set aside for testing
> >                 dormant:     not signaled (for a backup tunnel)
> >                 ready:       signaled but not yet carrying traffic
> >                 operational: signaled and carrying traffic."
> >
> > Paths that are operational carry packets.  Others don't.
> >
> > If a tunnel has multiple operational paths, it is an implementation
> > decision how packets of an LSP are assigned to paths: round-robin,
> > hash-based, random, ...  Specifying this in the MIB is not usually
> > productive, especially as the common answer is hash-based, and the
> > hashes used are usually proprietary.
> >
> > Kireeti.
>