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

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 16 Mar 2004 10:06:32 -0800

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:[email-masked]]
Sent: Tuesday, March 16, 2004 9:56 AM
To: Adrian Farrel; Brungard, Deborah A, ALABS; [email-masked]
Subject: RE: ason-routing-reqts: issue 2 architecture

Hi Adrian

See Comments Below,

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Monday, March 15, 2004 4:18 PM
> To: Brungard, Deborah A, ALABS; [email-masked]
> 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" <[email-masked]>
> To: <[email-masked]>
> 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

---

From: [email-masked]
Date: Tue, 16 Mar 2004 19:48:26 +0100

the problem is not an issue of being cleaner, the issue
is once the following assumption is taken (which is the
logical consequence of rfc 3630 in the gmpls context)

"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."

can we assume that wrt to this stable IP address the
resource identification will be unique (throughout
these multiple data plane entities) and in this case
it holds (no additional level of indirection needed),
or not (i.e. you will find duplicated id space values
and then an additional level of indirection is needed)

the problem of the design team was not define the issue
but to find enough arguments wrt to the operational
practices (ie user community) in order to close this

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