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

From: <[email-masked]>
Date: Sat, 23 Jul 2005 13:15:19 +0100

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:[email-masked]] 
Sent: 23 July 2005 00:08
To: Harrison,N,Neil,IKM1 R
Cc: [email-masked]
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

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 23 Jul 2005 06:49:31 -0700 (PDT)

Neil,

[SNIP]

> types of network you will indeed understand what I

This kind of statements you've been making in about
every email. I am curious to know as we move towards
the duct which *exactly* features, provisioning
functions or operations that are implemented via NMS
could not be conceptually realized via control plane? 
Or you are not the "right folk to ask" ? :=)

My view wrt Ethertnet GMPLS is this. I have no doubts
that we can come up with mechanisms to dynamically
provision L2SC LSPs. My problem is the order of
events. It does not seem to me wise to come up with
some control plane framework and solution(s) and after
that think what we need to do in the data plane. It
seems to  me wiser to learn how to statically
provision such LSPs, see how useful they are, and only
after that design and develop ways to provision them
dynamically.
In other words, it is wiser to repeat what has been
done with TDM LSPs.

Cheers,
Igor

> > this 'IP control plane' nonsense.
=== message truncated ===

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 23 Jul 2005 18:43:18 +0200

hi igor,

[snip - hint: igor i suggest you create a thread on control vs 
management plane]

> provision L2SC LSPs. 

ouf ;-)

> My problem is the order of events. 
> It does not seem to me wise to come up with
> that think what we need to do in the data plane. 

actually, if this is the only problem you have, i should underline we do 
not have to initiate the definition of a specific forwarding paradigm so 
i am not necessarily sure about what you mean by the last part of the 
above sentence

> It seems to  me wiser to learn how to statically

i am not sure to follow how are you going to determine the benefit from 
dynamic provisioning by statically configure these LSPs ?

> In other words, it is wiser to repeat what has been

wiser ? ... would you clarify ? don't you think it is more appropriate 
to receive feedback on the appropriateness of the use of GMPLS for the 
scenarios depicted in the problem statement document rather than digress 
on non-rational argument such as "wiser", "careful" or so... ?

>>>An IP control-plane?  There is actually no such
>>
>>animal.  Just what 
>>
>>>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 
>>
>>>but an 'IP Control Plane' per se means absolutely
>>
>>nothing to me....
>> 
>>>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.
>>
>> 
>>>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
>>
> .

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 24 Jul 2005 08:05:32 -0700 (PDT)

Dimitri,

What I was trying to say here is that for the User how
TE Ethernet connection is established - via control or
management planes is of a little importance. Before
explaining how cool/elegant it could be provisioned
via GMPLS you need to answer IMO the following
questions:

1) What does it mean Traffic Engineered Ethernet
connection in the data plane and what is it good for?
For instance, we perfectly understand what does ATM
connection or TDM connection mean in the data plane
and can provide references to corresponding data plane
standards.

2) How does the label-aware Ethernet forwarder
co-exist with other Ethernet forwarders on the same
switch

3) What information is necessary to provision the
forwarding tables?

And so on.

Cheers,
Igor

--- dimitri papadimitriou <[email-masked]>
wrote:

> >>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
> >>only being used as the transport protocol in the
> OOB
> >>data-plane network
> >>- uses IP addresses to identify data plane
> resources
> >>within 
> >>  the control plane

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 24 Jul 2005 18:30:48 +0200

igor

> management planes is of a little importance. 

-> in the CCAMP context where the second C means "Control" it is of 
importance because the purpose of this working group is to define IP 
control plane mechanism(s)

> Before

-> i suggest you also take a look to section 3 and 4 and if you think 
there are additional arguments you would consider as part of these 
sections i would suggest that you share them with us

> and can provide references to corresponding data plane

-> i suggest you take a look at scenario 2 for inst. that should in 
principle provide an answer to your question

> co-exist with other Ethernet forwarders on the same

-> it is an explicit non-objective of THIS document to detail (existing) 
Ethernet forwarding behaviour and their co-existence, in part. due to 
point 3) here below

> 3) What information is necessary to provision the

-> the current document refers to "label" entries without delving into 
details but this has been done purposely as the choice which will 
ultimately be made (e.g. VLAN Tags, or new TPIDs or something else) is 
orthogonal to be capabilities this working group wants to achieve with 
GMPLS control of Ethernet networks

> And so on.

-> in practice ?

>>>My view wrt Ethertnet GMPLS is this. I have no
>>
>>doubts
>>
>>>some control plane framework and solution(s) and
>>
>>after
>>
>>>provision such LSPs, see how useful they are, and
>>
>>only
>>
>>>after that design and develop ways to provision
>>
>>them
>>
>>>dynamically.
>>
>>>In other words, it is wiser to repeat what has
>>
>>been
>>
>>>done with TDM LSPs.
>>
>>>>that carries the control/management-plane
>>
>>protocols.
>>
>>>>
>>>>Perhaps I should have said "IP-based control
>>
>>plane".
>>
>>>>- uses protocols developed for use in the
>>
>>Internet.
>>
>>>>
>>>>>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.
>>>>
>>>>

---

From: Bijan Jabbari <[email-masked]>
Date: Mon, 25 Jul 2005 04:55:31 -0400

While we are on the subject of control vs. management plane and the need for
GMPLS-based control of Ethernet TE, I thought it might be worthwhile to
indicate some prior work done in this area and within the context of an
experimental optical and IP network (although a few of you might be familiar
with this activity, as my colleagues or myself might have shared with you the
goal of the project which also involves establishing Ethernet/L2 LSPs).

  As part of this project (referred to as DRAGON, initiated in the early 2003
and supported by the NSF), we have implemented the GMPLS capabilities (OSPF-TE
& RSVP-TE) within an element (referred to as the Virtual LSR, or VLSR) 
and have
used it within experimental and demo networks to control Ethernet, TDM and
Fiber-switched capable switches. The implementation is open source software,
available free to public and it runs on FreeBSD or Linux.

  While VLSR participates in a GMPLS-based control network from one end, it
enables the devices (Ethernet switches, cross-connects, etc. without GMPLS
capability) to participate within the network, by translating specific 
protocol
events into an appropriate sets of commands for the device to effect an
associated state change.

  In our use of VLSR to control Ethernet switches, the LSP set up requests are
processed by issuing the appropriate SNMP commands to the said device to place
two ports into a single VLAN effecting a port-to-port cross-connect. For
control of Ethernet switches, we have used RFC 2674 to dynamically modify VLAN
configurations.

  Efforts are underway to add multi-region capability to VLSR, where we 
can have
the ability to route light-paths across different networks 
transparently. A case
of interest there is to cater to the PSC LSP when no existing path to the
destination might exist, however a lower layer path, say an Ethernet 
L2SC path,
could be established to provide the missing link for the PSC request.

  Regards,
  - Bijan

Quoting dimitri papadimitriou <[email-masked]>:

> -> it is an explicit non-objective of THIS document to detail 
> (existing) Ethernet forwarding behaviour and their co-existence, in 
> part. due to point 3) here below
>
> -> the current document refers to "label" entries without delving 
> into details but this has been done purposely as the choice which 
> will ultimately be made (e.g. VLAN Tags, or new TPIDs or something 
> else) is orthogonal to be capabilities this working group wants to 
> achieve with GMPLS control of Ethernet networks
>
>> And so on.
>
> -> in practice ?
>
>> Cheers,
>> Igor
>>
>>> [snip - hint: igor i suggest you create a thread on
>>> control vs management plane]
>>>
>>>
>>>> My problem is the order of events. It does not seem to me wise to 
>>>> come up with
>>> actually, if this is the only problem you have, i
>>> should underline we do not have to initiate the definition of a specific
>>> forwarding paradigm so i am not necessarily sure about what you mean by the
>>> last part of the above sentence
>>>
>>>
>>> i am not sure to follow how are you going to
>>> determine the benefit from dynamic provisioning by statically 
>>> configure these
>>> LSPs ?
>>>
>>>
>>> wiser ? ... would you clarify ? don't you think it
>>> is more appropriate to receive feedback on the appropriateness of the
>>> use of GMPLS for the scenarios depicted in the problem statement document
>>> rather than digress on non-rational argument such as "wiser", "careful"
>>> or so... ?
>>>
>>>
>>>> Cheers,
>>>> Igor
>>>>
>>>>
>>>>
>>>>
>>>>> From: Adrian Farrel [mailto:[email-masked]] Sent: 23 July 2005 00:08
>>>>> within the control plane
>>>>> given above define a control plane based on IP. It is undoubtable 
>>>>> that attempts have been made to
>>>>> use control planes
>> http://mail.yahoo.com .