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

[Ashok Narayanan <[e-mail]>]

On Tue, Mar 08, 2005 at 03:20:43PM -0000, [e-mail] wrote:
> 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.

Maybe that division is not as clear as it needs to be. Which network
of those two do the following belong to?:

1) Path message for an optical LSP generated by a PSC edge node.
2) NOTIFY message from a PSC edge node to the other PSC edge node for
an optical LSP. 
3) Path message for a frame LSP going over an optical LSP generated by
a PSC edge node. 
4) LDP messages exchanged between PSC edge nodes.
5) SIP messages transiting the PSC edge nodes.

There are plenty of different control plane levels here, so rather
than talk about two specific ones, I would like to differentiate
between 

a) "Messages for GMPLS/TE routing/signalling of optical LSPs between
the PSC edge devices and the optical core devices"

b) "everything else".

I want to say that if we use a separated control network for "a)",
then any and all traffic for "b)" MUST NOT go over that control
network. Everything else is to clarify (and may insert additional
ambiguities of its own :-()

> 
> Network (1) has to be OOB as a forced requirement of the co-cs mode.

Not necessarily OOB, but "separated". I think this is the point that
Dimitri was making. DCC is not necessarily considered OOB, but it is a
separated control plane. 

> Network (2) does not have to be OOB but it may be (it's down to operator choice/policy etc.).

Yes, and the specific statement is that traffic in network 2 cannot
transit the separated control plane used for network 1. Whether it is
separated or not is not relevant as you correctly point out.

> 
> 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.  

I agree. I would phrase this as a "clarification" of b) above;
clarifying that PSC layer network control traffic falls in the
"everything else" category w.r.t the optical network.

> This behaviour should be recursive from the lowest to
> the highest layer in the network stack.

That's not necessarily what I'm saying but it's not bad. 

> 
> 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)
> > 

-- 



--- 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)