Subject: RE: path taken by a packet feedback

From: [email-masked]
Date: Thu, 26 Sep 2002 21:50:39 +0100

I agree, maybe for different reasons...please see below.

regards Neil

> -----Original Message-----
> From: Petre Dini [mailto:[email-masked]]
> Sent: 26 September 2002 20:04
> To: Kireeti Kompella
> Cc: [email-masked]; [email-masked]; Petre Dini
> Subject: Re: path taken by a packet feedback
> 
> 
> At 11:11 AM 9/26/2002 -0700, Kireeti Kompella wrote:
> > > 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
> 
> I think one must capture the distinction between a "down_1" due to a 
> signaling failure, and an ordered  "down_2", i.e.,  an 
> "abnormal down" 
> versus a "normal down".
NH=> When I 1st saw this mail I wondered should I correct this?   What has
'down' (of the data-plane) got to do with 'down' of the signalling (in the
control-plane)?   There is no reason why these should be connected in either
the class of network technologies that belong to co pkt-sw or co cct-sw.  Of
course control and data planes are congruous in the cnls network case....but
this case does not require signalling anyway.
> 
> >                 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."
> 
> To avoid naming confusion (operational state and and 
> operational value of 
> the operational state), I suggest "functional" for the path 
> operational 
> state 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.
> 
> Petre
> 
> 
>

---

From: "Truong Dieu Linh" <[email-masked]>
Date: Thu, 26 Sep 2002 17:37:29 -0400

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.

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

---

From: Petre Dini <[email-masked]>
Date: Thu, 26 Sep 2002 20:06:11 -0700

At least, let us synchronize the reasons, see the sandwiched text labeled 
<petre>.
-- Petre

<petre>
I see that "down" on the data-plan could be connected
with a "down" at the control-plan, but semantically they
are different.

Data-plan:
State "down" at the data-plan certainly means
that a path was somehow in
one of the other states, (i.e., Kiteeti's testing,
dormant, ready, or ...functional.)
Here I am not sure that all these states
apply to the data-plan (see below).

Control-plan:
State "down" has no sense in the same semantic.
It assumes that a path, was,
at the data-plan in one of the active state values.
In here, I see a path being in the status of "initiated",
"failed", "in_negotiation", ..."established", etc.
Once "establised", at he data-plan one may have
various data-plan related state values.

I suspect that in_test must be a state value at both
data-plan and control-plan, with different semantics:

data-plan: the nature of traffic data is test oriented;
data is inserted by a testing entity, not originally
intended by the scope of establishing a path.establishment.

control-plan: to avoid any other use, this state prohibits the
two entities originally intended to cooperate through this
path to interact.

Based on what I se at control-plan, I see that at data-plan
one may only have "dormant", "intentionally_suspended",
and "active".

I see, once the value spaces are stable, we may envisage
what kind of dependency exists between two states belonging
respectively to data-plan and control-plan of the same path.
This will drive the derivation of path control polices in the
control-plane.

What is your reason, then?

Other observations:

The state "unknown" must refer to the control-plane.
I do not see this in the data-plan.

I'm going to explore a little bit more co vs cnls, as
it appears to me we should consider this aspects.
<petre>