Subject: RE: ason-routing-reqts: issue 2 architecture

From: "Stephen Shew" <[email-masked]>
Date: Tue, 16 Mar 2004 17:04:17 -0500

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:[email-masked]] 
Sent: Tuesday, March 16, 2004 16:37
To: [email-masked]'; Adrian Farrel
Cc: Fedyk, Don [BL60:1A00:EXCH]; Brungard, Deborah A, ALABS;
[email-masked]
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: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, March 16, 2004 12:58 PM
To: Adrian Farrel
Cc: Don Fedyk; Ong, Lyndon; Brungard, Deborah A, ALABS; [email-masked]
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" <[email-masked]>
> To: <[email-masked]>; "Ong, Lyndon" <[email-masked]>
> Cc: "Adrian Farrel" <[email-masked]>; "Brungard, Deborah A, ALABS"
<[email-masked]>; <[email-masked]>
> 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: [email-masked]
>>>[mailto:[email-masked]] 
>>>Sent: Tuesday, March 16, 2004 1:48 PM
>>>To: Ong, Lyndon
>>>Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard, 
>>>Deborah A, ALABS; [email-masked]
>>>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:[email-masked]]
>>>>Sent: Tuesday, March 16, 2004 9:56 AM
>>>>To: Adrian Farrel; Brungard, Deborah A, ALABS; [email-masked]
>>>>Subject: RE: ason-routing-reqts: issue 2 architecture
>>>>
>>>>
>>>>Hi Adrian
>>>>
>>>>See Comments Below,
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Adrian Farrel [mailto:[email-masked]]
>>>>>Sent: Monday, March 15, 2004 4:18 PM
>>>>>To: Brungard, Deborah A, ALABS; [email-masked]
>>>>>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?

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Mar 2004 22:26:53 -0000

Seems you are all a bit hung up on the definition of a "router".

Because GMPLS comes from a perspective where an LSR was a router was a single bearer plane device you are assuming that the identity advertised it the router id. But really the "TE router id" is the physical node id (or the logical router id - Ln in my figure).

Stephen has it when he says...

> In that case, it would be confusing to scope the P1-P2 link using the router

This is exactly right. And why would you scope the P1-P2 link using the router id of R1?
Why not use the node id P1 or the logical router id L1?

Adrian