Re: Stepping back from the ASON Routing Discussion

[Kireeti Kompella <kireeti@juniper.net>]

Hi Jonathan,

On Wed, 17 Mar 2004, Jonathan Sadler wrote:

> > The first sentence is about requirements.
> > Do we, or do we not, need to support advertising UNI Transport Resource address prefixes?
>
> There is a requirement to be able to advertise reachability (G.7715
> sec7.1.1, G.7715.1 sec 9.4).  G.7715.1 states:
>   Reachability Information: Reachability information describes
>   the set of endpoints that are reachable by the associated node.
>   It may be advertised either as a set of UNI Transport Resource
>   addresses/address prefixes, or a set of associated
>   SNPP IDs/SNPP ID prefixes, the selection of which must be
>   consistent within the applicable scope.
> so technically, there isn't a requirement to advertise UNI Transport
> Resource Addresses -- the requirement is to advertise reachability
> in terms of SNPP IDs or UNI Transport Resources Addresses.

Thanks for the references!  This is exactly what I want to see.  What
I don't want is an ITU-T Liaison complaining that we are re-doing
their requirements :-)

> It should be noted that there is a unique attribute of SNPP Prefixes
> and UNI Transport Resource Addresses -- they exist independant of
> layer networks.  More specifically, UNI Transport Resource Addresses
> are used to name an Access Group Container, where the Access Groups
> within the Container can be in one or more layer networks.  So, it
> cannot be assumed that a specific UNI Transport Resource Address is
> in Layer Network A or B.

Okay, noted.

> > 2.
...
> > Do we, or do we not need to support a physically separated
> > architecture with a 1-n relationship between control plane and
> > transport plane entities?
>
> Yes.

If you have references, that would be great.  In my reading (I'll look
for the reference), I understood this to be: ASON doesn't restrict the
architecture to physically co-located or to physically separate, i.e.,
a particular solution may do either.  In that case, unless GMPLS
supports both, we should just state which approach GMPLS takes.

(As an aside, I'm not convinced that GMPLS is restricted to a single
box architecture.  The combination of GMPLS and GSMP should yield a
non-co-located architecture.  However, this may not be as well-fleshed
out as one wishes.  But this is orthogonal to the requirements.)

> > 3.
...
> > The requirements questions are:
> > A. What does ASON require in terms of evolution of hierarchies?
>
> The requirements stated in G.7715.1 are:
>   "...the routing protocol shall be capable of supporting
>   architectural evolution in terms of number of hierarchical
>   levels, as well as aggregation and segmentation of RAs."
>
> This is further illustrated as being:
>  - Segmentation of one Routing Area into two separate RAs
>  - Aggregation of two RAs into one RA
>  - Renaming of RAs
>  - Insertion of an RA into the hierarchy
>  - Deletion of an RA from the hierarchy
>
> Insertion and Deletion can be done at any point in the hierarchy --
> it is not limited to just the top or bottom of the hierarchy.

Perfect.

> > B. Are these requirements immediate and high priority?
>
> No statement of immediate/high priority exists in the ASON documents
> for any ASON requirement.

That's a good point.  When we liaize (forgive me!) this back to the
ITU-T SG14, we should mention that we have prioritized the
requirements, and ask if they have comments on that.

Thanks again for bringing us back to the DT charter!

Kireeti.
-------