I agree with Lyndon and Don regarding the need to have a bearer plane identifier for the node. To answer Adrian's first question, the RFC3630 makes the assumption that the link is scoped to a router. Another quote from RFC3630 is "The Link ID sub-TLV identifies the other end of the link. For point-to-point links, this is the Router ID of the neighbor.". This derives from the assumption that a "router" is both a control entity and a packet forwarding entity (bearer) and that they are 1:1.
What ASON does is describe a control plane architecture that can be instantiated a number of ways onto a G.805 bearer plane. A link in that context is always associated with a (G.805) subnetwork which is also a bearer entity. The smallest subnetwork is a matrix or node/switch. So applying the ASON principle, the link is scoped to a node and not a control entity (routing) or its identifier (router id).
One instantiation that is possible would be for R1 in Adrian's diagram to advertise on behalf of each of the P1/P2/P3 nodes, not as one abstract node. In that case, it would be confusing to scope the P1-P2 link using the router id of R1.
-----Original Message-----
From: Ong, Lyndon [mailto:LyOng@Ciena.com]
Sent: Tuesday, March 16, 2004 16:37
To: 'Dimitri.Papadimitriou@alcatel.be'; Adrian Farrel
Cc: Fedyk, Don [BL60:1A00:EXCH]; Brungard, Deborah A, ALABS; ccamp@ops.ietf.org
Subject: 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?