[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CCAMP WG Last Call on GMPLS Routing Documents
Hi Vishal and Suresh:
Vishal Sharma wrote:
> 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.
Sure. I agree with you. Node capability is something new to be
cosidered in path computation. This is subset of the domain
considrations we had in the SRG document.
>
>
> Of course, it would have to be used in signaling for path setup
> (depending on how path setup is initiated).
Agreed.
>
>
> 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.
Agreed too. That is the reason why I responded to a part of his
message. One remark though, SRG will not reduce the overhead
of path computation - from my internal implementation experience :-)
I was only commenting to the P&R portion.
>
>
> 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.
>
We are in sync.
>
> -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
> >