RE: Flooding using LMP extensions

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

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
>