RE: ason-routing-reqts: issue 2 architecture

["Ong, Lyndon" <LyOng@Ciena.com>]

I had the same assumption as Don, that the RFC treats the
advertising router and the bearer plane node as the same.
It would be cleaner if there was also a bearer plane node
identifier in the advertisement.

Cheers,

Lyndon

-----Original Message-----
From: Don Fedyk [mailto:dwfedyk@nortelnetworks.com]
Sent: Tuesday, March 16, 2004 9:56 AM
To: Adrian Farrel; Brungard, Deborah A, ALABS; ccamp@ops.ietf.org
Subject: RE: ason-routing-reqts: issue 2 architecture


Hi Adrian

See Comments Below,

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
> Sent: Monday, March 15, 2004 4:18 PM
> To: Brungard, Deborah A, ALABS; ccamp@ops.ietf.org
> Subject: Re: ason-routing-reqts: issue 2 architecture
> 
> 
> I assume that the desire is to have one control plane entity 
> mange multiple data plane entities (not to have one data 
> plane entity managed by multiple control plane entities).

I agree.
> 
> I believe. in this context, it might be helpful to separate 
> the signaling function (and the associated routing function 
> for the delivery of the signaling messages) from the TE 
> advertisement routing function. Since we are discussing the 
> routing requirements (this is the routing DT) can I assume 
> that the discussion is limited to the TE advertisement 
> routing function, with the aim to have one control plane 
> entity advertise the resources on behalf of multiple data 
> plane entities.
> 
> If all of the above, why could you not simply do this using 
> RFC3630? The only wrinkle might be that the Router Address 
> TLV is described as carrying "a stable IP address of the 
> advertising router". Clearly, this needs to be interpreted as 
> "a stable IP address of the control plane entity that manages 
> the resources on behalf of the data plane entity whose 
> resources are being advertised."

Interesting. I thought that you need a logical node id for the bearer plane
as well even though you are only advertising from a single entity.  In other
words, is it not the desire to have the TE advertisements contain the same
information regardless of whether there is a one to one correspondence
between the nodes in control and the data plane or there is a one to many
relationship? My interpretation of RFC3630 is that it assumes the
advertising router is the same as the logical node in the bearer plane that
owns the resources. If a logical node id was added to the advertisement for
the node terminating the resources when the advertising router was not the
bearer node that owned the resources it would be clearer to me. 

Don 


> 
> Am I missing something?
> 
> Adrian
> 
> ----- Original Message ----- 
> From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
> To: <ccamp@ops.ietf.org>
> Sent: Monday, March 15, 2004 7:43 PM
> Subject: ason-routing-reqts: issue 2 architecture
> 
> 
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-
02.txt

The second DT issue is on the physical architecture which can be supported
by GMPLS (from the draft):

ASON does not restrict the architecture choices used, either a co-located
architecture or a physically separated architecture may be used. Some
members of the Design Team are concerned that GMPLS's concept of the LSR
requires a 1-to-1 relationship between the transport plane entity and the
control plane entity (Router). They invite CCAMP input on GMPLS capabilities
to support multiple architectures i.e. how routing protocols would identify
the transport node ID vs. the router or routing controller ID when scoping
Link IDs in a link advertisement. Deborah