RE: ason-routing-reqts: issue 2 architecture

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

Hi Dimitri,

Can you reference the quote?  Thanks (could not find it
in 3630).

Also one side note - one thing to keep in mind is that
people on the transport network side may be looking at
the routing protocol to provide more than just pure
connection routing functions, e.g., it may also provide
a topological map of the transport network in a way that
is easier to access than using the management system to
contact each node.  In this regard, you could have a single
control plane entity managing many data plane entities and
still want to advertise the existence and connectivity of
the data plane entities.

Cheers,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, March 16, 2004 10:48 AM
To: Ong, Lyndon
Cc: 'Don Fedyk'; Adrian Farrel; Brungard, Deborah A, ALABS;
ccamp@ops.ietf.org
Subject: Re: ason-routing-reqts: issue 2 architecture


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.

Ong, Lyndon wrote:
> 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
> 
> 
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491