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?
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