Re: Stepping back from the ASON Routing Discussion

["Adrian Farrel" <adrian@olddog.co.uk>]

Vishal,

I think what you describe is business as usual for hierarchies.
This is clearly a requirement that needs to be captured, but it is nothing startling or
controversial (I believe).

Thanks,
Adrian
----- Original Message ----- 
From: "Vishal Sharma" <v.sharma@ieee.org>
To: "Adrian Farrel" <adrian@olddog.co.uk>; <Dimitri.Papadimitriou@alcatel.be>; "Don Fedyk"
<dwfedyk@nortelnetworks.com>
Cc: <ccamp@ops.ietf.org>
Sent: Thursday, March 18, 2004 7:43 PM
Subject: RE: Stepping back from the ASON Routing Discussion


> 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
> >
> >
>
>
>
>