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

RE: ason-routing-reqts: issue 1 addressing



Hi Kireeti,

Please see below.

Lyndon

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


Hi Lyndon,

On Tue, 16 Mar 2004, Ong, Lyndon wrote:

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

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.

[LYO] OK, point taken.  This is already a GMPLS requirement.

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

[LYO]  Well, I was not asking for this to be put into the 
requirements document, just trying to present some of the
concerns with the conclusions section.

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.

[LYO] G.7713.1 is a signaling document (and as Jon points out does
have a mechanism for carrying IP addresses).  PNNI routing extensions
for ASON would need a mechanism for advertising UNI
reachability.

Thanks,
Kireeti.
-------