RE: CCAMP WG Last Call on GMPLS Routing Documents

["Vishal Sharma" <v.sharma@ieee.org>]

Sudheer,

I would think that the capability of a node or link really needs to
be part of the routing protocol, at least from a "distribution of
information" perspective.

Of course, it would have to be used in signaling for path setup
(depending on how path setup is initiated).

Also, I think Suresh's reference in asking for additions to routing
wasn't directed at the several proposals directed at simplifying
path computation and restoration, such as SRG.

Rather, it seems to point to some specific equipment/technology
capabilities
that need to be included in routing for the routing to be fully
applicable for the SDH/SONET case.

-Vishal

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Sudheer Dharanikota
> Sent: Tuesday, April 09, 2002 8:32 PM
> To: Suresh Katukam
> Cc: ccamp@ops.ietf.org
> Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents
>
>
> Hi:
>
>
> Suresh Katukam wrote:
>
> > These routing documents do not cover many SONET/SDH cases at all.
> > Even though it is generic routing, SONET/SDH is included in these and
> > do not take care of TSI (Time Slot Interchangable) issues and protection
> > related issues.
> >
> > Here is the list of issues:
> >
> > 1. Certain links are TSI capable - and certain are not. In this
> case, one
> > needs to know the group of nodes that belong to this category (e.g.
> > Ring ID for BLSR ) so that one can do path computation properly.
>
> Some people feel that such requirements are to be part of signaling and
> some feel that it should be part of the routing and signaling
> protocol. I belong
> to the second category. As Kireeti said, in the design team this is one of
> the issues we would like to address. There are some proposals already
> on the table to address some of these issues...
> draft-many-ccamp-srg-01.txt is one such draft.
>
> - sudheer
>