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

[<[e-mail]>]

Ashok,

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.  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.  Fine, I agree that is the BCP, but I don't believe the current draft articulates that intent very well and section 7.4 probably needs expanding (IMO one or two paragraphs is probably not enough to discuss/address/detail OOB Vs in-band properly and unambiguously), for example it is not IMO clear from the current text that you are talking about 2 separate control plane networks - one OOB (for non-PSC layer networks/nodes) and one inband (for PSC layer networks/nodes).

Thanks
Ben

> -----Original Message-----
> From: Ashok Narayanan [mailto:[e-mail]]
> Sent: 08 March 2005 12:59
> To: Niven-jenkins,B,Ben,XDE73 R
> Cc: [e-mail]
> 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.
> 
> 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, 
> [e-mail] 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: [e-mail]
> > tel: [phone]
> > mob: [phone]
> > 
> > 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: [phone] (Attn: Ashok Narayanan)
>