[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ason-routing-reqts: issue 2 architecture
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