[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ason-routing-reqts: issue 2 architecture

hi lyndon,

the question is not only to be more simpler for R1 (i don't think you are more simpler you're just mapping the hierarchy of the abstract node within the identification space) it is to so see how it impacts R2 and R3, in term of the processing, how it impacts the abstraction level that you want to achieve (do external R2 and R3 really care about the way R1 is performing id assignment) and finally what it brings in terms of control plane functionality, arguments like cleaner, or simpler (what simple means) are probably not be used in the present context, at the end the issue is about practice and relevance

it also clear that if this additional level of indirection is proven to be required nothing is said about the way to deliver it while you already assumed it must take the form of a node_id (why a node_id ? why not a shelve_id ? or a rack_id ?)

thanks,
- dimitri.

Ong, Lyndon wrote:

Hi Guys,

R1 was what I was referring to in my side note: it is
possible to treat P1/P2/P3 as separate
interfaces on a single abstract node, but you lose
information about the physical topology and
connectivity of the nodes. Also, this puts a constraint on the allocation of interface IDs across
multiple nodes. 

Would it not be simpler and more straightforward to
advertise P1/P2/P3 directly?

Cheers,

Lyndon

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


adrian,

yes, it reproduces the three cases, i had in mind over this
discussion

see in-line:


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 switch
R1 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 requirement



to support all them yes (i think that from a protocol
capability perspective it is advisable)


B. That this can be achieved using existing protocols 


there is no difference between R2 and R3 since the DP
to CP interactions were never part of the GMPLS routing
discussions:
- R2 <- Router_Address, R3 <- Router_Address
- If_Id assigned to each interface

for R1 (externally since representing an abstract node):
- R1 <- Router_Address
- If_Id assigned to each interface (with a value space
   common to P1, P2 and P3)

for R1 if there is a need to cover also the internal
(abstract node) links (is that the case?), in such a
case, the Link_Id sub-TLV value should be discussed


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 PM
Subject: 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





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