RE: Stepping back from the ASON Routing Discussion

[<neil.2.harrison@bt.com>]

Hi Adrian....I have been biting my tongue and trying hard to stay out of this....I have failed, but I'll try and keep it short.

You (and Vishal) are right....we have been doing hierarchies for years.  And there are not just technical issues wrt client/server layer network relationships (which is what transport hierarchies create), there are also commercial issues, ie different parties can own the client and server layer networks involved.

The problems arise when folks think they can converge (somehow) the 3 native network modes of cl-ps, co-ps and co-cs.  Sure you can try, but its a big mistake.  All these modes can be derived from applying constraints to the most basic network mode, which is 'broadcast at source, filter at sink'.  This is how humans communicate in a mtg, and its how ethernet works.  However, it does not scale.  So we introduce constraints.....and we do so to get benefits in simpler design/operations/management/etc.

Addressing and routing are the 1st set of constraints.....these provide a 'where' (not 'who') semantic and a limited directivity behaviour.  This gets us to the cl-ps WAN mode best exemplified by IP.  Adding signalling (ie controlling the directivity further) gets us to the co-ps mode.....and it has implications on the nature of the forwarding traffic unit, ie this can be simplified to simply contain a link-connection ID (ie label) and not a full DA/SA pair (as required for the cl-ps mode).....the addresses are now only related to the trail access points.  If we add further constraints to the forwarding traffic unit we end up with the co-cs mode, ie now fixed BW, labels become some time/freq/space metric and (*very* significantly) there are no traffic/QoS classes.

However, all these modes have very different behaviours, eg the faults that can affect each mode are very different and the arch constructions that are allowed are different (I'll resist explaining why certain types on MPLS break the arch rules).  The simple fact is they all do different jobs optimally and we thus need them all.  The last thing one should be doing is trying to converge them all.....its simply wrong and folks who try this will continue to hit problems. (What we do want however is convergence *within* each mode, ie no point in having lots of co-ps technologies say.....just leads to stovepipe proliferation (ie technology=service) and downstream i/w problems).

We require our suppliers to understand/respect the func arch stuff of layered networks that is detailed in G.805/809...everything flows from these, esp the management information models.  And we were instrumental in doing the control-plane func arch of G.8080.  

I'll stop at that point since I am sure you can fill-in where I am heading now ;-)

regards, Neil

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Adrian Farrel
> Sent: 18 March 2004 23:19
> 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
> > >
> > >
> >
> >
> >
> >
> 
> 
>