Subject: RE: ason-routing-reqts: issue 1 addressing

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 16 Mar 2004 13:46:04 -0800

Hi Dimitri,

Maybe the issue needs to be worded more clearly...

Can existing address reachability mechanisms support
(and if so, how)

a) distinguishing between the control plane address
for a client and the data plane address for a client
which might be two different things?

b) distinguishing between the internal network address
space and an external client address space?

c) advertising reachability to a client whose address 
space is non-IP?

Cheers,

Lyndon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, March 16, 2004 11:43 AM
To: Ong, Lyndon
Cc: 'Brungard, Deborah A, ALABS'; [email-masked]
Subject: Re: ason-routing-reqts: issue 1 addressing

hi lyndon,

some hints in-line, i start worrying about the arguments
you've been listed here below since here except (2) they
are not related to this issue 1:

Ong, Lyndon wrote:

> Hi Folks,
> 
> Let me kick off some discussion on issue 1 by noting some of the 
> concerns with using existing methods of advertising reachability for
> this purpose:
> 
> 1) the client system may not be an IP system, but another transport 
> device with an IP control interface - for example, an ADM (add-drop 
> multiplexer) acting as a client to an optical network.  Advertising 
> reachability using normal means might imply that the system can be 
> used for IP traffic routing.

-> the SC capability of the end-point is orthogonal to its
    numbering (in addition, this way of thinking will make us
    advertising MAC addresses when end-points will terminate
    Ethernet)

> 2) the client system may use a different addressing space than the 
> internal network addressing space.  Carriers may wish to use a 
> different addressing space for administrative or policy reasons.

-> i don't think there is any discussion here, the thread
    focuses on "external" reachability - and this is the
    issue, how this "external" reachability information
    needs to be advertised to maintain the properties of
    the control plane (in particular scalability)

> (Note: one model for this is the VPN model, which would allow private
> networks to have their own address spaces.  Another model is a
> telephone number-like model, where clients obtain addresses from a
> space maintained by the carrier.)
> 
> 3) the client system may use a non-IP address for compatibility 
> reasons, for example, a client with an existing management plane 
> address that the carrier wants to access without having to add a new
> address and translation mechanism.

-> mapping of MP <-> CP and CP <-> DP are outside the scope
    of the present discussion, note if your argument was valid,
    the argument (2) wouldn't since in this case you would
    have been advertising your management plane addresses

> Cheers,
> 
> Lyndon
> 
> -----Original Message----- From: Brungard, Deborah A, ALABS
> [mailto:[email-masked]] Sent: Monday, March 15, 2004 11:29 AM To:
> [email-masked] Subject: ason-routing-reqts: issue 1 addressing
> 
> 
> As noted in the CCAMP minutes and the DT's presentation, the ASON
> routing DT had three issues regarding GMPLS support for which they
> lacked agreement and request support of the WG. The issues are
> identified in Section 7 (Conclusions) of the draft: 
> ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
> 
> 
> I will post three separate email threads to cover each issue. The
> first issue is on address reachability. The following is the text
> from the draft:
> 
> Some members of the Design Team noted that reachability information
> (as described in Section 4.5.3) may be advertised as a set of UNI
> Transport Resource address prefixes (assigned and selected
> consistently in their applicability scope). These members of the
> Design Team raised a concern that existing methods of advertising
> reachability may need to be examined (on a per-protocol basis) to
> determine if they are also applicable for UNI Transport Resource
> addresses. They invite CCAMP discussion on this aspect. 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

---

From: [email-masked]
Date: Tue, 16 Mar 2004 23:12:15 +0100

hi lyndon,

> which might be two different things?

there is no "data plane" address under discussion here
all entities carried in the control plane are control
plane objects - you may want to reformulate this as
is there any specific need to carry a separate set of
values that translates the reachable end-points ?

i restate that if there was DP addresses to be carried
their mapping should be maintained locally the CP

> space and an external client address space?

and "external reachable end-points" you mix this the
client address space

> c) advertising reachability to a client whose address 

i don't understand, most (if not all) devices we are
discussing here are non-IP terminating devices, how
this differentiates the clients from network nodes
from that perspective ?

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 18 Mar 2004 11:47:05 -0800 (PST)

Hi Lyndon,

> c) advertising reachability to a client whose address

All excellent questions.  Thanks for the summary.

I'll go back to my meta-question:

Are these ASON routing requirements?  If so, can you quote chapter and
verse?  The clear charter of the ASON Routing Reqts DT is to take
*existing* ASON routing requirements, evaluate them against what's in
GMPLS routing, and come up with a list of remaining requirements to
set the stage for an ASON Routing Extensions document.  Not to come up
with new requirements, however excellent they may be.

Kireeti.
-------