[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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