[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
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, benjamin.niven-jenkins@bt.com 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:ashokn@cisco.com]
> > Sent: 08 March 2005 12:59
> > To: Niven-jenkins,B,Ben,XDE73 R
> > 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.
> >
> > 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)
> >
--
--- 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)