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

RE: ason-routing-reqts: issue 1 addressing



Hi Kireeti,

I would like to put this discussion in some perspective:
we were discussing unsettled areas in the conclusions section, 
which currently states that "no additional 
extensions seem to be required in order to advertise reachable 
end-points within an ASON control plane."

I'm concerned that this can be read as a conclusion about the
routing protocols rather than routing requirements, and if
so seems premature and out of scope of the requirements document.

As Jon has pointed out, the specific requirement in ASON
is to advertise reachability in terms of a set of SNPP IDs
or UNI Transport Resource Addresses or associated prefixes.

ASON does not specify in detail how UNI Transport Resource
Addresses are formatted or allocated (apart from specifying 
that they are globally unique and network assigned).  If
GMPLS has restrictions that affect reachability advertisement
it would be helpful to understand this.

Cheers,

Lyndon


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


Hi Lyndon,

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

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

All excellent questions.  Thanks for the summary.

I'll go back to my meta-question:

Are these ASON routing requirements?  If so, can you quote chapter and
verse?  The clear charter of the ASON Routing Reqts DT is to take
*existing* ASON routing requirements, evaluate them against what's in
GMPLS routing, and come up with a list of remaining requirements to
set the stage for an ASON Routing Extensions document.  Not to come up
with new requirements, however excellent they may be.

Kireeti.
-------