RE: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt

[<[e-mail]>]

Ashok,

I think one of the key points that needs highlighting explicitly which is not clear in the draft or your text below is that there are two separate control networks:
1) One control network for the non-PSC core. 
2) One control network for the PSC edge nodes.

Network (1) has to be OOB as a forced requirement of the co-cs mode.
Network (2) does not have to be OOB but it may be (it's down to operator choice/policy etc.).

If you look at the whole network stack you have trails in the non-PSC core layer network supporting link connections in the PSC layer network.  These non-PSC layer network trails may be used to support link connections in the PSC layer network that may be assigned to carry only 'PSC data traffic' (for the PSC data plane), only 'PSC control traffic' (for the PSC control plane when it's taken OOB) or both 'PSC data and control plane traffic' (when the PSC control plane is inband wrt the PSC data plane).  

In other words, the non-PSC layer network has it's own data & control plane networks that are (or should be) decoupled from the PSC layer network (which has its own data & control plane networks).  non-PSC layer network data plane trails can be used to support PSC layer network data (and/or control) plane link connections, but non-PSC layer network control plane trails MUST NOT be used to support PSC layer network data (and/or control) plane link connections.  This behaviour should be recursive from the lowest to the highest layer in the network stack. 

Ben

> -----Original Message-----
> From: Ashok Narayanan [mailto:[e-mail]]
> Sent: 08 March 2005 14:52
> To: Adrian Farrel
> Cc: Niven-jenkins,B,Ben,XDE73 R; [e-mail]
> Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
> 
> 
> On Tue, Mar 08, 2005 at 02:12:54PM -0000, Adrian Farrel wrote:
> > Hi,
> > 
> > Ben summarized...
> > 
> > > Thanks for the explanation.  If I understand correctly 
> what you are
> > > saying is that the best current practice is to use an OOB 
> control plane
> > > for the non-PSC  layer networks and an in-band control 
> plane for the
> > > PSC layer networks.
> > 
> > If that is the intention of the authors of this draft, they 
> will have to
> > fight me :-)
> 
> I better check out this website:
>  http://www.all-karate.com/how_to_learn_karate.php
> 
> > I do not see why an in-band control channel for a PSC 
> network would be
> > made a RECOMMEND, SHOULD or MUST.
> 
> That is certainly not the recommendation (phew). 
> 
> I clarified in a separate email, but basically the point we are making
> is that in an optical GMPLS/TE network with optical switches in the
> core and PSC devices on the edge, edge-to-edge protocols not used for
> GMPLS/TE signalling within the core must be kept off the separated
> control network. I think the text needs to be tightened up to say
> this; I sent out an alternative formulation just now, let's see how
> that goes.
> 
> > 
> > >  So one must avoid using the control plane network (of a non-PSC
> > > layer network) for the transfer of data (or control) 
> plane packets from
> > > the PSC layer network's control & data planes.
> > 
> > Yes. But more precisely, one must avoid using the control 
> channels for
> > data traffic. Even in-band control channel may use a 
> different address
> > space, and those addresses must not be used for data.
> 
> Which is fine, but then raises the question: what is "data"? Bearer
> traffic? SIP messages transiting through a number of hops to get here?
> IPv4 RSVP for QoS? BGP or LDP running between the PSCs? I claim that
> for the aforementioned "GMPLS/TE-optical-core-PSC-edge" network, *all*
> of the aforementioned must be kept off the separated control plane
> *used for GMPLS within the optical core*. Nothing prevents these other
> protocols from having their own separated control plane, just as long
> as that other control plane also goes over a GMPLS/TE LSP or via some
> other "data" path.
> 
> What I'm trying to say is that the optical switches in the core should
> basically not have to ever see any signalling or data packets that
> don't pertain to GMPLS/TE signalling within the optical core.
> 
> In summary: (is this a better way to write this in the draft?)
> 
> 1) A core of optical switches with PSC edge devices running GMPLS may
> use a separated control network (DCC, OOB Ethernet, or some other) to
> carry GMPLS/TE signalling messages. Further, this control network may
> be low-bandwidth and may pass through devices that are not well suited
> for IP routing.
> 
> 2) Bearer data traffic transiting this network MUST NOT be carried on
> this separated control network.
> 
> 3) Further, given the nature of the control network and the devices
> that maintain it, protocols running between the PSC edge devices that
> are not used for GMPLS/TE signalling within the core MUST NOT be
> carried over this control network. (N.B. should this be relaxed to a
> "SHOULD"?) This does not preclude these other protocols from running
> separated control planes of their own, as long as the protocol
> signalling messages do not transit the separated control network used
> within the GMPLS/TE core.
> 
> -Ashok
> 
> 
> 
> 
> 
> 
> 
> --- Asok the Intern ----------------------------------------
> Ashok Narayanan
> IOS Network Protocols, Cisco Systems
> 1414 Mass Ave, Boxborough MA 01719
> Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)
>