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