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

[dimitri papadimitriou <[e-mail]>]

ashok - this section is indeed to be clarified

1. for non-PSC it should distinguish the logical from the physical 
control channel separation with respect to the data plane channels, i do 
not see for instance why DCC channels could not be used to exchange 
control plane traffic and still keep a logical separation

2. for PSC - why is there something different in terms of "practice" 
than what is currently used in MPLS networks ?

or

3. do you assume that the interconnection of a PSC with non-PSC network 
(both driven by GMPLS) could indeed introduce change from the current 
practices operators used to use for their packet networks ? that in case 
could be further applied to PSC-only networks ?

thanks,
- dimitri.

Ashok Narayanan wrote:

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