[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: path taken by a packet feedback
Neil, Pete,
Even in a cnls protocol the control plane has ample responsibilities. For every new packet the data plane may potentially need to talk to the control plane, for various reasons from next hop to classifications/rules, etc.
So as far as failure is concerned it can't be tolerable. However, if and when the control plane fails (with the redundant one down too) the obvious thing that the data plane can do is forward the packets to the next hop for whatever ones it can make a decision and drop the ones that it does not know how to make a decision with a least common denominator being a null set.
So the point being that whether it is cnls or co networks it will react in a similar manner. The larger impact of it happens on the absolute source of the packet and the sink of that packet where state related to the packet is maintained. These generally happens on the desktops/loptops/servers etc and not in an intermediate router/switch. The intermediates do not have much of a state that they do have to maintain (I say that in cheek and tongue as some do have minor operational states that are kept, but they do happen to reside within the data plane path).
My two cents ;-)
SG
*********** REPLY SEPARATOR ***********
On 9/27/2002 at 1:55 PM neil.2.harrison@bt.com wrote:
>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
>> > >
>> > >
>> > >
>>