RE: path taken by a packet feedback

[neil.2.harrison@bt.com]

Petre,

Thanks....you asked for my reason?  I thought I stated it?  However, I will
try and expand a little but I don't want to create a large mail thread on
this please.

All network types (of which there are 3: cnls, co pkt-sw and co cct-sw)
require addressing + routing functions....these are said to lie in the
'control-plane'. In cnls networks the control (and any management) plane
protocols all go through a single data-plane as does the traffic.  This is
not true in co networks.  co networks also need a signalling function to
instantiate the trail (and even management plane provisioning is a sort of
signalling if you think about it).  In co networks there can be several
disjoint data-planes (logically for sure, and possibly physically) for
traffic and control protocols (and even management protocols).  So, when we
are considering any co technology great care has to be taken to ensure
correct behaviour under failures.  For example, if a I create a VPN say with
long-holding data-plane (traffic) trails I don't want failures of the
control-plane (be it it's own data-plane, or a signalling/routing protocol
say) to take down the traffic data-plane.

That is all I was saying.

regards, Neil 

> -----Original Message-----
> From: Petre Dini [mailto:pdini@cisco.com]
> Sent: 27 September 2002 04:06
> To: neil.2.harrison; pdini
> Cc: kireeti@juniper.net; te-wg@ops.ietf.org; truongtd@iro.umontreal.ca
> Subject: 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
> > >
> > >
> > >
>