RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]

[<neil.2.harrison@bt.com>]

Title: Message

Ok thanks Adrian,

 

Re-reading what I wrote and your response (and John's) I can see I did an awful job of trying to explain what I really meant...and I'm not surprised you responded as you did.  So my apologies for letting frustration get the better of me.  Trying to express it better:

 

Its simply not true that one can have a 'common' control-plane approach from IP to Optics.......for many reasons such as: the modal differences demand different approaches, who owns what layer network, the notion that one can create topology on the fly, the commercial factors that govern GoS network build-out, the relative importance of the control-plane vs the management plane (which also varies with network mode and where you are in the stack), etc.

 

However, if you go back some time the impression that was originally 'sold' to folks was that there IS this common control-plane from IP to Optics.  This view may have mellowed now, but I still see evidence of it of every now and then....and its when I see things that IMO are being somewhat 'economical with the truth' that I tend to react.

 

I also don't like it when folks go break architectural rules and 'pretend its OK/good'.  This is not generally an issue in CCAMPs as its jolly hard to do much damage to the co-cs mode....but you can for sure create havoc in the co-ps mode.   And at the end of the day arch violations and functional omissions/deficiencies end up as operational problems and opex costs in our networks.  If more folks understood functional architecture stuff I suspect this would help control this particular issue better.

 

We therefore have the real situation that there is no forced technical reason to be prescriptive in the choice of control-plane functional components when we are dealing with our major SDH/OTN co-cs transport networks.....which, of course, also have nothing to do with the public Internet   That is, they can be chosen on a best-of-breed basis.  

 

I am also a little concerned that some folks might naively assume that a control-plane is going to solve all their management-plane issues......when we move down the network stack to the duct there are a whole raft of factors that mean the management-plane still dominates here.  If you talk to the right folks in the operators who run these types of network you will indeed understand what I mean by this.

 

A control-plane is useful in the major co-cs transport networks (mainly for S-PVCs and resilience) but its a minor player compared to role of the management-plane.   The converse of course holds in a *traffic* carrying cl-ps  IP network, esp when this is in the context of the public Internet.....but of course this isn't the case here and IP is only being used as the transport protocol in the OOB data-plane network that carries the control/management-plane protocols. 

 

These were points I wanted to make.....hopefully I've done a better job this time.

 

regards, Neil

 

 

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: 23 July 2005 00:08
To: Harrison,N,Neil,IKM1 R
Cc: ccamp@ops.ietf.org
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]

Hi Neil,

 

I think John beat me off the blocks here, but...

> > GMPLS assumes an IP control plane.
>
> An IP control-plane?  There is actually no such animal.  Just what

> the heck does that REALLY mean in GMPLS say?

 

Let me explain.

Perhaps I should have said "IP-based control plane".

I mean a control plane which:

- uses IP as its network protocol

- uses IP addresses to identify control plane resources

- uses IP addresses to identify data plane resources within

  the control plane

- uses protocols developed for use in the Internet.

 

> I am not questioning IP as a cl-ps networking protocol *carrying*

> a signalling protocol (RSVP-TE, or dare I mention PNNI, or any

> signalling protocol yet to be invented) or a routing protocol

> (OSPF or ISO or whatever)

 

I am glad to hear it.

 

> or even management protocols

 

Fine, but not in the remit of CCAMP.

 

> but an 'IP Control Plane' per se means absolutely nothing to me....

 

Well, I think it should. I think the list of attributes that I have given above define a control plane based on IP.

 

It is undoubtable that attempts have been made to use control planes based on other protocols. Some have been highly successful. Some have been less fortunate.

 

> ...nor should it to anyone else. 

 

I think folks who were around at the beginning of CCAMP and who were part of the debate with the IESG will be very familiar with where the IETF draws the line here.

 

 

> I think some folks might need a reality check here....and also

> on the self-assumed importance of a control-plane. Hint: It ain't

> that important.....the management-plane (which may be using IP!)

> however is.

 

I am not sure how to interpret this.

It may be that you think that control plane is bad per se, but you have said elsewhere that you think it has value - but much less than the management plane.

It may be that you believe that CCAMP is willfully neglecting the management plane. This would, in fact, be true. It is not in CCAMP's remit to look at the management plane. Other SDOs are working to establish common standards for management of network devices across multiple vendors - we can wish them luck.

Clearly some people (vendors and providers) see sufficient value in a control plane to invest time and energy.

> The (hype) party is over for the OTN start-ups.  IP per se does NOT

> define a *control-plane*...IP is cl-ps networking techology period

> ....and its jolly important, but PLEASE don't try and feed me any of

> this 'IP control plane' nonsense.

 

Tush.

 

> Adrian....you are far smarter than this IMO and should know better.

 

Thanks for the endorsement. May I quote you?

 

Adrian