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

RE: path taken by a packet feedback

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


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

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

At 09:50 PM 9/26/2002 +0100, neil.2.harrison@bt.com wrote:
I agree, maybe for different reasons...please see below.

regards Neil

> -----Original Message-----
> From: Petre Dini [mailto:pdini@cisco.com]
> Sent: 26 September 2002 20:04
> To: Kireeti Kompella
> Cc: te-wg@ops.ietf.org; truongtd@iro.umontreal.ca; 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
>
>
>