RE: Stepping back from the ASON Routing Discussion

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

Adrian, et al,

You mention that there are two developments of the following requirement:

["It is a requirement of ASON routing to support networks that contain
devices
that do not contain the capabilities to participate fully (or at all) in the
routing protocols run within the network."]

The second development listed below seems to assume that the islands within
the network will not be represented to the routing protocol only when they
contain devices that do not support routing.

However, this is where I would appreciate some clarification to
help clear some of my understanding of this discussion.

It seems to me that while one implication of the above requirement
is certainly this, it is also possible that islands are not represented
to the routing protocol, simply because the provider does not wish to
reveal the topology of its network beyond a certain level of granularity
(even if the devices do support routing protocols within those islands).

This would be increasingly so when hierarchy is implemented. (The devices
could then support routing at a given level of the hierarchy, but may be
abstracted at the next (higher) level.)

While I understand that the current discussion focuses initially on a given
level of the hierarchy, I think the second development you talk about
below is also a consequence of the need to support hierarchy.

Or, did I not get it right?

-Vishal

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Adrian Farrel
> Sent: Thursday, March 18, 2004 3:43 AM
> To: Dimitri.Papadimitriou@alcatel.be; Don Fedyk
> Cc: ccamp@ops.ietf.org
> Subject: Re: Stepping back from the ASON Routing Discussion
>
>
> Don,
>
> Just picking out one snippet...
>
> > >>Do we, or do we not need to support a physically separated
> > >>architecture with a 1-n relationship between control plane
> > >>and transport plane entities?
> > >
> > > I would say yes. The requirement I see here is devices not capable of
> > > participating fully in GMPLS routing.
>
> I had to read this several times before I got it. Sorry.
>
> You mean that...
> "It is a requirement of ASON routing to support networks that
> contain devices that do not
> contain the capabilities to participate fully (or at all) in the
> routing protocols run
> within the network."
>
> That sounds a reasonable requirement.
>
> There are two developments of this requirement.
>
> The first is where the routing responsiblity for the device is
> taken on "by proxy" by a
> control plane entity such as one that Lyndon, Jonathan and I have
> been drawing. In this
> case, although the device is not participating in the routing
> protocols within the
> network, it is fully represented and there are no issues
> (although we must ensure that
> this function is covered by the requirements).
>
> In the second case, ther are islands within the network which are
> simply not represented
> to the routing protocol. This gives me a greater problem. Clearly
> you cannot route through
> a part of the network unless it appears to be connected in the
> TEDB. In this case, I
> suggest that what is needed is to represent those (legacy?)
> devices/subnetworks as
> Forwarding Adjacencies or virtual TE links. This requires some
> advertisement by a control
> plane entity on behalf of the devices/subnetworks, but does not
> expose the details of the
> connectivity of the devices that do not support routing.
>
> Some of you may (from time to time) hear me burble on about the
> fact that soft permanent
> LSPs should not simply cover the case where the permanent part is
> at the edge of the
> network. When I ramble in this way, I am talking about the second
> case, above.
>
> Cheers,
> Adrian
>
>