Subject: RE: ason-routing-reqts: issue 2 architecture

From: "Don Fedyk" <[email-masked]>
Date: Tue, 16 Mar 2004 23:08:21 -0500

Hi Dmitri

I had to leave and then I answered some of this already so I'll be brief. 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> 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>

---

From: [email-masked]
Date: Wed, 17 Mar 2004 12:09:00 +0100

don,

> least 2 ways to do it and both may be required in the end.

(1) that's fine, we reached the first discussion point which is how 
local representation of such construct can be done and achieved, it 
clearly shows there are several ways (btw, i assume here that we agreed 
on the "external" link representation)

(2) the second point of discussion is how much of this information is 
really needed externally (ie the common set of information) and a common 
semantic to what it represents to make the control plane working in a 
standardized and interoperable way (note: point (1) discussion showed 
that what's internal will be more elaborated than what is externally 
known and this in any case)

-> it seems that the following responds to the question: "A collection 
of links and nodes such as a subnetwork or RA must be able to represent 
itself to the wider network as a single logical entity with only its 
external links visible to the topology database.)" can we agree on this one

(3) and then, but i don't think we will be capable to enter into that 
discussion for the time being since back to the functional requirements:
- (3a) what's needed to represent this information in the routing
   protocol
- (3b) and what's needed as routing mechanism to exchange this
   information

thanks,
- dimitri.

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491