[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
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)
>