Re: GMPLS Routing Drafts

[Yangguang Xu <xuyg@lucent.com>]

Manoj,

First, I've to confess that I haven't read the related drafts very carefully.
Below is just what I think. 


>                My thinking is totally different. I am saying that what is
> the advantage of having control channel network information in routing
> protocols.
>
> Say I have following type of network. There are some SDH/SONET interfaces
> between the nodes. According to what u are saying, that routing databases at
> each of these nodes are aware of IPCCs (between each of these) and data
> channel/interfaces. But I am saying that routing protocol should be aware of
> only the data interfaces. It should not be aware of control channels. As
> control channel information is not going to change dynamically, this can be
> statically configured. For e.g. I can configure that for data
> channels/interfaces say 1..10 the list of vaious CCIds to use. For different
> data channel/interfaces, I can use different set of control channels. Only
> information that the routing module be aware of is about data
> channels/interfaces.
> 
>            A ---> B  ---> C
>                   |
>                   |
>                   V
>                   D
> 
> Do u feel that control channel information is a dynamic information (i.e.
> going to change very often) ?
> 

Control channel information is not dynamic in the normal case. But it could be
very dynamic in case of network failure, migration, upgrading etc. 

Actually, your thinking is not different from mine but addresses a different
perspective. In GMPLS, logically there are two routing "entities", one for the
control traffic, one for the user traffic. You are right that the routing entity
for user traffic doesn't care about the topology etc. of the control plane
network. However, in the implementation, both topology information could be
disseminated through a same engine (or "protocol"), the control plane network
OSPF or ISIS. So I don't see disagreement but misunderstanding. Am I right,
Kireeti?

Thanks,

Yangguang





> Regards,
> manoj.
> 
> >From: Yangguang Xu <xuyg@lucent.com>
> >To: manoj juneja <manojkumarjuneja@hotmail.com>
> >CC: kireeti@juniper.net, ccamp@ops.ietf.org
> >Subject: Re: GMPLS Routing Drafts
> >Date: Wed, 01 Aug 2001 19:25:50 -0400
> >
> >Manoj,
> >
> >I think Kireeti is right. Probably the confusion comes from "control
> >channels".
> >It's actually a control network running OSPF or ISIS. The control network
> >topology doesn't need to be the same as the data plane topology. However,
> >you
> >can assume that each pair of network elements have IP reachability through
> >the
> >control network. GMPLS transport network topology is disseminated through
> >opaque
> >LSA (in case of OSPF). At each NE, there are two logical topology
> >databases. One
> >for the control plane network, a vanilla IP network. Another one is for the
> >data
> >plane network, similar to OSPF-TE topology database.
> >
> >Regards,
> >
> >Yangguang
> >
> >manoj juneja wrote:
> > >
> > > Hi Kireeti,
> > >             I have read the second last para of the draft. It
> > > states "We call the interfaces over which regular routing adjacencies
> > > are established "control channels". This definition restricts its scope
> > > to routing adjacencies i.e. the control channels over which OSPF
> > > control packets are going to be sent. Does this mean for sending the
> > > GMPLS control messages, the same routing adjacencies are going to be
> > > used ? If yes, then how to distinguish between the control channels
> > > between two OSPF instances and GMPLS instances ? If no, then how this
> > > GMPLS control channel information is transmitted in routing protocols ?
> > >
> > > Regards,
> > > manoj.
> > >
> > > >From: Kireeti Kompella <kireeti@juniper.net>
> > > >To: ccamp@ops.ietf.org
> > > >Subject: Re: GMPLS Routing Drafts
> > > >Date: Wed, 1 Aug 2001 12:26:44 -0700 (PDT)
> > > >
> > > >Hi Manoj,
> > > >
> > > > > In section 5.1 of Ist draft, it is mentioned
> > > > > that "control channels are advertised into routing as normal links
> >as
> > > > > mentioned in previous section". But in previous section of document
> >I,
> > > > > there is no reference of control channels.
> > > >
> > > >Read the second last para of section 5.
> > > >
> > > > > Furthermore, in OSPF
> > > > > extensions document (IInd draft), there is no mention of control
> > > > > channels at all.
> > > >
> > > >Control channels are part of "regular" OSPF; the GMPLS OSPF draft
> > > >deals with the formats of the GMPLS TE extensions.  As the abstract
> >says:
> > > >
> > > >    This document specifies encoding of extensions to the OSPF routing
> > > >    protocol in support of Generalized Multi-Protocol Label Switching
> > > >    (GMPLS).  The description of the extensions is specified in [GMPLS-
> > > >    ROUTING].
> > > >
> > > >BTW, since you have a penchant for pedantry, let me point out that
> > > >it is inconsistent to call a "missing reference" (or a "no mention")
> > > >an "inconsistency".
> > > >
> > > >On the other hand, we do appreciate your careful reading.
> > > >
> > > >Kireeti.
> > > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> >
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp