[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ason-routing-reqts: issue 2 architecture
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)
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
Don
-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, March 16, 2004 1:48 PM
To: Ong, Lyndon
Cc: Fedyk, Don [BL60:1A00:EXCH]; 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
--
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