RE: Flooding using LMP extensions

["Vishal Sharma" <v.sharma@ieee.org>]

Hi Rick,

Actually, the answer to your question is "No, you're not."

The protection paths are computed (usually) assuming a single
fault in the network. That is, the protection path computation algorithm
assumes a certain fault in the network, and then computes backup
paths for working paths affected by this fault. (It repeats
this process for all single faults.)

If the particular fault actually does occur, the working paths
affected by the fault can be switched, by the recovery entity,
to their respective protection paths.

If dynamic path computation is performed upon the occurrence
of a fault, then too, the computation algorithm at a recovery
entity can compute backup paths once it learns (via fault
notification) of the fault (i.e, of the nature and location
of the fault).

The convergence of the routing algorithm is only helpful for _every_
network node to (eventually) update its routing database, and figure
out the new topology.

BTW, when flooding-based notification is used, every network node would, in
fact, know
of the fault, but this would be via the signaling function of the control
plane,
and would not necessarily lead to the updating of its routing table (which
would
be updated when the routing engine at a node learnt of the fault through the
routing protocol updates).

-Vishal

> -----Original Message-----
> From: Ruiquan jing [mailto:jingrq@ctbri.com.cn]
> Sent: Sunday, June 22, 2003 8:10 PM
> To: v.sharma@ieee.org; ccamp@ops.ietf.org
> Subject: RE: Flooding using LMP extensions
>
>
> Hi Vishal,
>
> I agree with you that G.7715 is about ASON routing.
> As for restoration, I think you still need the routing table to compute
> the restoration paths. And this could only began after the routing table
> is converged.
> Am I right?
>
> Thanks!
>
> rick
>
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Vishal Sharma
> Sent: Saturday, June 21, 2003 4:57 AM
> To: Ong, Lyndon; rick king; Roberto Albanese; ccamp@ops.ietf.org
> Subject: RE: Flooding using LMP extensions
>
>
> Hi Lyndon,
>
> Thanks a lot for your observations, and for the clarification
> on the meaning of an "SNPP link."
>
> Some comments in-line.
>
> -Vishal
>
> > -----Original Message-----
> > From: Ong, Lyndon [mailto:LyOng@Ciena.com]
> > Sent: Friday, June 20, 2003 11:05 AM
> > To: 'v.sharma@ieee.org'; rick king; Roberto Albanese; ccamp@ops.ietf.org
> > Subject: RE: Flooding using LMP extensions
> >
> >
> > Hi Vishal,
> >
> > I haven't been following this discussion closely, but
> > I think you are right in distinguishing routing from
> > signaling as functions in the control plane.  Some of
> > the confusion may be in the term SNPP link, in ITU
> > terminology this is a representation of connectivity
> > between different subnetworks for routing purposes,
> > so for example it may include multiple link connections
> > that share the same characteristics.
>
> Great, thanks.
> I do think that Rick has been referring to ITU specs. dealing
> with the routing functions of the control plane, whereas
> the focus in the "Flooding using LMP extensions" email thread
> is really on signaling functions of the control plane.
>
> > Knowing the state of an SNPP link would not tell you the
> > state of individual connections using the SNPP link,
> > which would be a signaling function.
>
> Appreciate the explanation. This is actually an important
> distinction, which underscores the importance of having a signaling
> function in the control plane, especially for P&R.
>
> -Vishal
>
>
> > -----Original Message-----
> > From: Vishal Sharma [mailto:v.sharma@ieee.org]
> > Sent: Thursday, June 19, 2003 6:28 PM
> > To: rick king; Roberto Albanese; ccamp@ops.ietf.org
> > Subject: RE: Flooding using LMP extensions
> >
> >
> > Rick,
> >
> > Thanks for the pointer. I now have a better idea of what you
> > were referring to earlier.
> >
> > Actually, there is no conflict between the discussion we're currently
> > having and the ITU description. (One (the ITU description below)
> > refers to, what I would call, "routing related" updates in the control
> > plane, while the other (the discussion we're having) refers to,
> > what I would call, "sigaling related" updates in the control plane.)
> >
> > Except that in the rabbat-draft, the so called "signaling" (or,
> > more accurately, fault notification) is achieved via flooding.
> >
> > The ITU description you've provided below refers to _routing related_
> > activity in the control plane. (That is, if a link state changes, the
> > control plane -- RC, RDB, etc. -- have to learn about it and make the
> > required
> > updates.)
> > In fact, this is what will happen in an IP-controlled transport
> > network also. The routing information and related databases _will_,
> > eventually, be updated. (And, at that time, one may
> > more optimally route those circuits that have been switched to recovery
> > paths in the meantime.)
> >
> > We, however, are talking about recovery here. This includes steps that
> > have to occur _in the interim_ to ensure that traffic flow is not
> > disrupted (or disrupted as little as possible). So there has to
> > be a way to inform the affected nodes of the failure for them to
> > take action.
> > _This_ is what we've been discussing on this thread.
> >
> > I don't think the ITU documentation is implying at all
> > that the routing-related updates be the means of fault
> > notification.
> >
> > -Vishal
> >
>
>