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

From: "Don Fedyk" <[email-masked]>
Date: Tue, 16 Mar 2004 12:55:57 -0500

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?
> 
> Adrian
> 
> ----- Original Message ----- 
> From: "Brungard, Deborah A, ALABS" <[email-masked]>
> To: <[email-masked]>
> 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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 16 Mar 2004 14:09:44 -0800

Hi Dimitri,

I understand, I think, that for processing purposes there may
be an impact to identifying P1/P2/P3 as opposed to R1.
However, isn't the ability to distinguish P1/P2/P3 as
separate physical nodes very important to the routing of
a connection across the network?  It is actually not so
important to know if they are controlled by a single
routing entity or not, except for maintaining the routing
protocol itself.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, March 16, 2004 1:59 PM
To: Ong, Lyndon
Cc: Adrian Farrel; Don Fedyk; Brungard, Deborah A, ALABS;
[email-masked]
Subject: 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
> 
> 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]
> 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.
>>
>>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 
>>>
>>>
>>>
>>>>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]
>>>>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
>>>>>
>>>>>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,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>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 
>>>>
>>>>
>>>>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 : [email-masked]
>>>>E-mail : [email-masked]
>>>>Webpage: http://psg.com/~dpapadimitriou/
>>>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>>>Phone  : +32 3 240-8491
>>>>
>>>>
>>>
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Tue, 16 Mar 2004 16:10:54 -0600

Hi Don,

The different terminology used in ITU/IETF may be what is causing confusion. This issue is not on how a control plane entity identifies it's own associated data plane resources. The question is what does a control plane entity (via I-NNI, E-NNI, UNI) "need to know" (to identify) of another control plane entity's resources? Here the example is on the "need to know" if multiple physical nodes are supported, others have suggested identifying physical locations, bays, individual circuit packs.

A key ASON requirement has been for the control plane to provide a logical abstraction of the physical resources (e.g. to "hide" internal physical implementations of a carrier, to support scalability, etc). If choose to use physical node ids for TEs, then this will always be the overriding constraint. Example, what if I want to bundle some resources of one node with another node for TE advertisement? We've had this limitation with management plane addressing, and only with the newer management models (Corba) are getting past it. Let's not go backwards.

Looking at the email activity, I see Adrian is also seeing this confusion, and has provided an example clarifying if we are discussing internal interfaces/GSMP or routing interfaces.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Don Fedyk
Sent: Tuesday, March 16, 2004 2:35 PM
To: [email-masked]; Ong, Lyndon
Cc: Adrian Farrel; Brungard, Deborah A, ALABS; [email-masked]
Subject: RE: ason-routing-reqts: issue 2 architecture

Dimitri

Don

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 16 Mar 2004 22:56:03 -0500

Hi Deborah

> From: Brungard, Deborah A, ALABS [mailto:[email-masked]] 
> Sent: Tuesday, March 16, 2004 5:11 PM
> 
> Hi Don,
> 
> The different terminology used in ITU/IETF may be what is 
> causing confusion. This issue is not on how a control plane 
> entity identifies it's own associated data plane resources. 
> The question is what does a control plane entity (via I-NNI, 
> E-NNI, UNI) "need to know" (to identify) of another control 
> plane entity's resources? Here the example is on the "need to 
> know" if multiple physical nodes are supported, others have 
> suggested identifying physical locations, bays, individual 
> circuit packs.

I think I answered that in Adrian's requirements question. And I'm confused
on terminology. 
> 
> A key ASON requirement has been for the control plane to 
> provide a logical abstraction of the physical resources (e.g. 
> to "hide" internal physical implementations of a carrier, to 
> support scalability, etc). If choose to use physical node ids 
> for TEs, then this will always be the overriding constraint. 
> Example, what if I want to bundle some resources of one node 
> with another node for TE advertisement? We've had this 
> limitation with management plane addressing, and only with 
> the newer management models (Corba) are getting past it. 
> Let's not go backwards.
O.K. I did not answer that part and I think the discussion will go on. The
requirements I put on NodeIds were simply to resolve Endpoints within and
area. I'm not a big fan of exporting real routing information out of the
area but if it is performed I would assume some form of abstraction would
take place that would present virtual nodeIds and links in the area. 

> 
> Looking at the email activity, I see Adrian is also seeing 
> this confusion, and has provided an example clarifying if we 
> are discussing internal interfaces/GSMP or routing interfaces.
> 
> Deborah
> 
Its a valid question. My belief is that in the spirit of RFC3630 what makes
a link a link and what makes a node a node is what is in question. Just
reusing the existing structure give me "links in space" when an entity does
the control plane for several objects. I know Dmitri was getting at this. My
instinct is telling me that if an entity in the control plane is routable
and logically could have GMPLS routing on it some day but does it by proxy
by some controller then it should have a node id. But if an entity is some
subset of a larger switch entity then it should perhaps be controlled by
GSMP and represented a single node.  The question comes down to do you
represent a set of entities a distributed switch or a set of nodes. 

Don   

> 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 
> 
> > is once the following assumption is taken (which is the logical 
> > consequence of rfc 3630 in the gmpls context)
> > 
> > >>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."
> > > 
> > >