[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ason-routing-reqts: issue 2 architecture
But this is just Forwarding Adjacencies, link
bundles and logical nodes, isn't it?
So let's state the requirement and move
on.
A collection of links and nodes such
as a subnetwork or RA must
be able to
represent itself to the wider network as a
single
logical entity with only its
external links visible to the
topology database.
Agreed?
Adrian
----- Original Message -----
Sent: Tuesday, March 16, 2004 10:08
PM
Subject: Re: ason-routing-reqts: issue 2
architecture
> Adrian -
>
> Yes, however it isn't limited to what you
have in the picture. Take the
> following picture:
>
>
Logical
>
Topology
+-++
>
--------+T1+--------
>
+--+
>
> Physical
> Realization
>
>
--------------- ---- ----
>
|R1 |
|R2 | |R3 |
>
| +-----------+ | |+--+| |+--+|
>
|
|L1 | | ||L2|| ||L3||
>
| +-----------+ | |+--+|
|+--+|
> |
: : : | | : | | :
|
>
-+-----+-----+- -+-- | : |
>
Control : :
: : | : |
>
----------+-----+-----+-----+----+-+--+-------
>
Data :
: : : |
: |
>
-+ : +-
: | +- |
>
------+P1+---------+P3+--------+|P5|+----
>
-- : /--\
: | -- |
>
\
-+- / \ +- / ----
>
\|P2 |/ \|P4|/
>
--- --
>
>
> L1, L2, and L3 are aware of the topology of P1-P5, and therefore
can
> progress a signalling request presented to L1 through the nodes, but
are
> not sharing it with the outside world. The only topology seen
is T1.
> The reason for doing this could be due to policy (hiding)
or
> scalability. (See draft-ietf-ipo-carrier-requirements for
more
> explanation on why this is good)
>
> Note here that
the Logical topology being advertized (characterized by
> Tn) is different
from the control plane realization (Ln) as well as the
> data plane
realization (Pn). This is possible in the ASON architecure,
> as
there is no limitation in how a function is realized.
>
> In this
case, you wouldn't be able to have separate Router IDs for each
> Pn, as
the single T1 shown above must use the same Router ID for the
> link
endpoint names in order make only a single node appear in the
>
topology. However, since the resource information for the link
>
ingressing at P1 as well as the link egressing at P5 are in R1 and R3,
>
it is problematic to have a single Router ID.
>
> Jonathan
Sadler
>
> Adrian Farrel wrote:
>
> > All,Does the
following picture capture what we want to
> >
achieve?
------------------ ------
> >
|R1
| |R2
| |
-- -- -- | |
> >
-- |
------ |
|L1| |L2| |L3| | | |L4| | |R3
> >
| |
-- -- -- | |
-- | | --
| |
>
> : : : |
| : | | |L5| |Control
> >
---+-----+-----+-- ---+-- |
-- |Plane
: :
> >
:
: | :
> >
|----------------+-----+-----+----------+------+---+--+-Data
> >
: :
:
: | :
|Plane
-- :
> >
--
-- | -- |
> >
----|P1|--------|P3|-------|P4|-----+-|P5|-+-
-- \ :
> > /
--
-- | --
|
\ --
> >
/
| |
> >
|P2|
------
-- Pn is a
> > physical (bearer/data/transport plane) node.Rn is a
control plane
> > "router"Ln is a logical control plane entity that
manages a single
> > physical node. Thus:R3 represents an LSR with all
components
> > collocated.R2 shows how the "router" component may be
disjoint from
> > the switchR1 shows how a single "router" may manage
multiple switches
> > If you can confirm this generalisation, then we
can show (or fail to
> > show)A. That this is a requirementB. That this
can be achieved using
> > existing protocols Cheers,Adrian. PS.
Those not familiar with GSMP
> > may want to take a quick peak. -----
Original Message -----From: "Don
> > Fedyk" <dwfedyk@nortelnetworks.com>To:
> > <Dimitri.Papadimitriou@alcatel.be>; "Ong, Lyndon" <LyOng@Ciena.com>Cc:
> > "Adrian Farrel" <adrian@olddog.co.uk>; "Brungard,
Deborah A, ALABS"
> > <dbrungard@att.com>; <ccamp@ops.ietf.org>Sent: Tuesday,
March 16, 2004
> > 7:34 PMSubject: RE: ason-routing-reqts: issue 2
architecture > Dimitri
> >
> > >
> > > 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.
> > >
> > > 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).
> > >
> > > 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).
> > >
> > > 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.
> > >
> > > 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.
> > >
> > >
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
>
> > >
> > > >
> > >
> >
>
>
>
>
>
-----------------------------------------
>
============================================================
> The
information contained in this message may be privileged
> and
confidential and protected from disclosure. If the
> reader of this
message is not the intended recipient, or an
> employee or agent
responsible for delivering this message to
> the intended recipient, you
are hereby notified that any
> reproduction, dissemination or
distribution of this
> communication is strictly prohibited. If you have
received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
>
> Thank you.
> Tellabs
>
============================================================