[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ason-routing-reqts: issue 1 addressing



Hi,

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Thursday, March 18, 2004 2:47 PM
To: Ong, Lyndon
Cc: 'Brungard, Deborah A, ALABS'; ccamp@ops.ietf.org
Subject: RE: ason-routing-reqts: issue 1 addressing


Hi Lyndon,

On Tue, 16 Mar 2004, 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.
xxxxxxxxxxxxxxxxxxxxxxxxxxx
[elv]

Just a quick side note - If one were dealing with routers as the clients, for example, I think there can still be an issue.

Each router has an IP address, which is routable in the IP layer space.  Of course, that's not the routable address in the optical space.  So if it is required that an optical routable address for the remote IP router be provided in the UNI message, the router will need to know:
+ the IP address of the IP router it wants to talk to for its IP layer operations, AND
+ the optical routable address that the router it wants to talk to is associated with.

Aside from making visible the edge optical NE routable addresses (security issue), the router will also need to track the equivalence between the two, as it will need to maintain the other router's IP routable address
in the forwarding table, as well as its optical layer routable address for UNI signaling purposes.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

There is a section in the GMPLS routing document titled:


1.2. Excluding data traffic from control channels

This section proposes one method for achieving this; and finishes by
saying:

   Other techniques for excluding data traffic from control channels may
   also be needed.

So, we all agree that this is a requirement.  I would not put this in
the ASON Routing Reqts doc, though, unless this is written in some
ITU-T Recommendation, given that the ASON Routing Reqts are *not* to
introduce new requirements, however useful or sane they may be for
ASON (or other) networks.

> 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.
>
> (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.

Again, these are both good, but unless you can find text to this
effect in an ITU-T Recommendation on ASON routing requirements, we
cannot put this in the ASON Routing Requirements document.

If there is such text (for any of points 1, 2 or 3), it would be
useful in the context of this debate to post it to this list.

For point 3, I view Recommendation 7713.1 which (in my faint
recollection) has only PNNI addressing, and in particular does not
have IP addressing, as suggesting that it is NOT a requirement that
a given solution cater to all possible address types.  So, while this
might a nice-to-have, it certainly doesn't seem to be an ASON
requirement.  If you think otherwise, please let me know --
Recommendation number & section.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[elv]  In Rec. G.807, Section 7.4 on naming and addressing, I've excerpted some points - hope this is helpful:

Separation of server layer name and client layer name, as well as user domain name and service provider domain name, provides an abstraction barrier between name processing and connection operations. Some properties of the naming and addressing in the switched network are:
.	Name independence: The client (user) name should not make assumptions on what capabilities are offered by the server (service provider) name, and thus the semantics of the two name spaces should be separate and distinct. This does not place any constraints on the syntax of client and server layer name spaces, or on the user and service provider name spaces.
.	Server layer name space: The server layer name space provides identification of the node and the resources available for connection operations at that layer. Server names are applicable at the server layer only, and should not be communicated to the client layer.
.	Service provider name space: The service provider name space provides identification of the node and the resources available for connection operations and is an NNI issue. Service provider names are applicable in the service provider domain, and should not be communicated to the user.
.    Name translation: This provides multiple purposes. The translation function may provide mapping of the client layer name to server layer name (used for routeing decision through the server layer), user domain name to service provider domain name, or provide mapping of connection identifier to a connection in the server layer. These translation functions will likely be performed via one or more directory services.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Thanks,
Kireeti.
-------