RE: ason-routing-reqts: issue 2 architecture

["Don Fedyk" <dwfedyk@nortelnetworks.com>]

Hi Dmitri

I had to leave and then I answered some of this already so I'll be brief. 
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be 
> [mailto:Dimitri.Papadimitriou@alcatel.be] 
> Sent: Tuesday, March 16, 2004 3:14 PM
> 
> 
> don,
> 
> > If you are saying the real or logical node id that is 
> associated with 
> > the Data (bearer) plane should be unique? I would say yes.
> 
> see below
> 
> > If you are saying could it be IP address format? I would say yes. 
> > (Note the link identifiers in IP address format are unique 
> only with 
> > respect to the node id).
> 
> see below
> 
> > But if you say Should it then follow each piece of equipment has 
> > knowledge of this IP address format that is assigned to it? I would 
> > say no because there is equipment that won't have this for 
> some time. (A requirement I
> > understand from ASON).   
> 
> i'll restate, because i think the issue is, can a CP entity 
> be assigned an IP address from which all links could be 
> addressed independently of their physical distribution 
> (single data plane entity or multiple data plane entity)

That depends on what you want to do with the information. What is the scope?
To identify links. Sure <IP, id>. That is unique. The question comes down to
are you representing a distributed node or a set of nodes that cannot speak
the right flavor of routing so they require a proxy. This is a valid
requirement for legacy equipment. 

> 
> > So what I believe you are left with is some bearer 
> equipment which has 
> > TE resources (a node Identifier (non-IP) and link identifiers 
> > (non-IP)). This equipment is known by its native identifiers to the 
> > entity in the control plane which can assign: IP format 
> identifiers to 
> > the equipment (through some
> > means) and an unique node identifier. This can then be 
> advertised on its
> > behalf as a GMPLS compatible TE LSA. 
> 
> again here, if the concatenation <IP address, id> allows to 
> uniquely identify all the "logical node end-points" at the 
> control plane level then independently of the native data 
> plane address space value, we're fine (there is no need to 
> duplicate the identifier of the owner of this space)
> 
> > This does create some challenges but in reality I think 
> many devices 
> > are known by more than one name. (Look at VoIP, devices they have 2 
> > identifiers E.164 and IP. I personally never use my IP 
> address to make 
> > a VoIP phone call but I know that it is routed to a IP 
> address along 
> > the way that is hidden from me.)
> > 
> > I tend to agree with Lyndon that Topology is derived from TE 
> > advertisements. I don't understand what you could do 
> without a unique 
> > logical node associated with the TE links.
> 
> i don't think the issue is on feasibility (both are here 
> feasible and works) it is to assess whether at the control 
> plane level an additional level of indirection is *required* 
> to identify the DP resources or not - and it just a practice 
> issue, does the user community assign an IP address to each 
> of their node and then on top another for the log. construct 
> that they can map to the router address or do they assign an 
> address for the logical construct and then number each of the 
> endpoints, it may even be that both are required, you will 
> also see that in each case the response to your 1st question 
> is yes and the second one as well
> 
> note: i'm not saying also that it is the only issue here, but 
> we have to start from somewhere in order to solve this

So Adrian took us back to requirements. But I think we agree there are at
least 2 ways to do it and both may be required in the end.

Don 

<snip>