RE: ason-routing-reqts: issue 1 addressing

["Ong, Lyndon" <LyOng@Ciena.com>]

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: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, March 16, 2004 11:43 AM
To: Ong, Lyndon
Cc: 'Brungard, Deborah A, ALABS'; ccamp@ops.ietf.org
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:dbrungard@att.com] Sent: Monday, March 15, 2004 11:29 AM To:
> ccamp@ops.ietf.org 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 : 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