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

[Ashok Narayanan <ashokn@cisco.com>]

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: 978-936-2218 (Attn: Ashok Narayanan)