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

[Ashok Narayanan <[e-mail]>]

Ben,

Thanks for the comment. We'll try to clarify this in the next version.

-Ashok

On Tue, Mar 08, 2005 at 01:14:08PM -0000, [e-mail] wrote:
> 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)
> > 

-- 



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