RE: Stepping back from the ASON Routing Discussion

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

Adrian,

Great, thanks. I just wanted to make sure, since hierarchy was
point 3 of the requirements email you sent.

-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:19 PM
> To: Vishal Sharma; Dimitri.Papadimitriou@alcatel.be; Don Fedyk
> Cc: ccamp@ops.ietf.org
> Subject: Re: Stepping back from the ASON Routing Discussion
>
>
> 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
> > >
> > >
> >
> >
> >
> >
>