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

[Ashok Narayanan <ashokn@cisco.com>]

> 
> I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> 
> The draft states:
> "PSC-capable nodes implementing an OOB control plane (perhaps to
> communicate with an optical switch) MUST NOT use the OOB control
> plane for data traffic.  For example, in the case of MPLS service
> running on top of a GMPLS LSP, if the peer PSC device is reachable
> via both the control plane and the data plane, control protocols
> such as LDP MUST NOT form adjacencies over the control plane
> interfaces.  This may be provided by a combination of implementation
> features and deployment guidelines."
> 
> So, if the control plane is OOB why must control protocols (such as
> LDP) NOT form adjacencies over the control plane interfaces?  This
> implies that LDP (for e.g.) MUST form its adjacencies over the data
> plane interfaces and therefore LDP is not running OOB (and therefore
> the control plane is not entirely OOB).
> 

That's an interesting question. The draft focuses on GMPLS/TE
deployments and the use of an out-of-band control channel as a matter
of necessity (i.e. because optical switches are not capable of
handling in-band control traffic). Consider the general deployment of
a core of optical switches surrounded by GMPLS/TE routers at the
edge. From the perspective of this network (optical switches, edge
routers, and the links in between), that statement translates to:

 _ The GMPLS/TE control plane between the edge routers and the optical
   switches in the core is entirely out-of-band

 - All other protocols between the edge routers MUST be entirely in-band.

The control plane network may well be a series of point-to-point GRE
tunnels overlaid on some other low-bandwidth network (actually this is
what the draft recommends). Ordinarily one would establish a GRE
tunnel between each pair of neighbors so they can talk to each other.
But this means that signalling messages going from edge router to edge
router actually have to be routed through the control planes of
intermediate switches. The two alternatives to avoid this (to create a
full mesh of GRE tunnels - at least between all the edge routers - or
to not use GRE at all if the control plane is switched Ethernet, and
therefore to essentially permit a full mesh of OSPF peers) are not
really palatable (and in the case of SDCC, not usable). The optical
switches in the core should not be in the business of routing
packets. Sometimes they have to (e.g. Notify messages), but they are
not designed for this purpose and should not be deployed as such.

And practically speaking the control network is expected to be a
low-bandwidth network that can "just get the job done". A single
10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the
control traffic for a GMPLS/TE network, but will probably fail if we
want to use it to peer LDP or BGP for 10,000 prefixes/labels between
the edge routers.

The best current practice is therefore to use the low-bandwidth
control network between routers and switches for GMPLS/TE signaling
(RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs
signalled between edge routers to do other L3 protocols between them.

The issue of a separated control plane between PSC edge routers for
different L3 protocols for administrative reasons is an interesting
one. Nothing precludes you from creating multiple parallel LSPs
between edge routers and using one of them to carry control traffic
between the two edge routers on behalf of all the others; that would
still satisfy this requirement. Alternatively, one could engineer a
more beefy control plane network so that it can in fact carry all the
control plane traffic (BGP, LDP etc.) but that is not the BCP today
based on available implementations.

-Ashok

On Tue, Mar 08, 2005 at 10:33:54AM -0000, benjamin.niven-jenkins@bt.com wrote:
> Colleagues,
> 
> I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> 
> The draft states:
> "PSC-capable nodes implementing an OOB control plane (perhaps to communicate with an optical switch) MUST NOT use the OOB control plane for data traffic.  For example, in the case of MPLS service running on top of a GMPLS LSP, if the peer PSC device is reachable via both the control plane and the data plane, control protocols such as LDP MUST NOT form adjacencies over the control plane interfaces.  This may be provided by a combination of implementation features and deployment guidelines."
> 
> So, if the control plane is OOB why must control protocols (such as LDP) NOT form adjacencies over the control plane interfaces?  This implies that LDP (for e.g.) MUST form its adjacencies over the data plane interfaces and therefore LDP is not running OOB (and therefore the control plane is not entirely OOB).
> 
> Thanks
> Ben
> 
> 
> -- 
> Ben Niven-Jenkins
> Networking Specialist, BT Exact
> 
> e-mail: benjamin.niven-jenkins@bt.com
> tel: +44(0) 1473 648225
> mob: +44(0) 7918 077205
> 
> pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK
> 
> BT Exact is a trademark of British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no. 1800000
> 
> This electronic message contains information from British Telecommunications which may be privileged or confidential. The information is intended to be for the use of the individual(s) or the entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. 
> 
> Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

-- 



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