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

["Rajiv Papneja" <rpapneja@isocore.com>]

See below:

-----Original Message-----
From: Ashok Narayanan [mailto:ashokn@cisco.com] 
Sent: Tuesday, March 08, 2005 7:59 AM
To: benjamin.niven-jenkins@bt.com
Cc: ccamp@ops.ietf.org
Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt

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

[rp] Furthermore - If LDP adjacencies are formed over the control plane, and
since the LDP forwarding is based on the IP routing and metrics, the PSC
devices will try to forward the IP traffic on the interfaces with the lowest
metric (control interface in this case), and since all the edge nodes in the
GMPLS control plane are adjacent from control plane traffic perspective, one
has to change the metrics of the control plane interface on the PSC devices
to avoid the best path through the control plane (OOB). 

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)