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

From: "Drake, John E" <[email-masked]>
Date: Fri, 22 Jul 2005 15:18:35 -0700

Neil,

Adrian is correct.  RSVP, OSPF/IS-IS, and BGP are the control plane protocols that are used to control an IP network.  GMPLS assumes the same set of control plane protocols.

Thanks,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 22, 2005 2:22 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls
> rnvironment.]
> 
> > 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?  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) or even management protocols
> but an 'IP Control Plane' per se means absolutely nothing to me....nor
> should it to anyone else.   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 this 'IP control
> plane' nonsense.
> 
> Adrian....you are far smarter than this IMO and should know better.
> 
> regards, Neil
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Adrian Farrel
> > Sent: 22 July 2005 19:13
> > To: Spencer,R,Richard,XDE73 R; [email-masked];
> > [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: Ethernet Control Plane [Was: Re: Frameformat in a
> > l2cs gmpls rnvironment.]
> >
> >
> > Whoa there!
> >
> > GMPLS assumes an IP control plane.
> > I am aware that there is work afoot in other SDOs to assign a
> > dedicated VLAN tag to specify the control plane traffic. This
> > is not what we are doing.
> >
> > As far as I am aware, everyone in the IETF is comfortable
> > with the idea of using IP packets to carry control plane data
> > through an IP-enabled DCN. In Ethernet the issue will be
> > whether the control plane is in band (use IP address and MAC
> > address) or out of band (use distinct DCN).
> >
> > The use of a separate VLAN ID to signify the control plane is
> > out of scope for CCAMP.
> >
> > Thanks,
> > Adrian
> >
> > ----- Original Message -----
> > From: <[email-masked]>
> > To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Friday, July 22, 2005 4:33 PM
> > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> >
> >
> > Juergen,
> >
> > Before you can use GMPLS to set up VLANs a data plane must
> > first exist to carry the GMPLS control plane traffic. Yes you
> > can use the standard Ethernet data plane for this purpose
> > (and in fact must do so for the solution to be viable), but
> > its not as simple as that. You cannot assume that just
> > because two GMPLS peers are directly connected that they can
> > communicate with each other.
> >
> > To exchange GMPLS control plane packets between a pair of
> > GMPLS peers, the peers will need to agree to use either
> > untagged control packets or to tag them with a common VLAN
> > ID. The use of a separate VLAN for GMPLS control traffic is
> > analogous to using a separate VLAN for management traffic
> > today. If two switches belong to the same management VLAN
> > then you can use ICMP ping to verify connectivity between
> > them. However, if one switch has been put into the wrong
> > management VLAN then the ping will obviously fail.
> >
> > If you want to use a separate VLAN for GMPLS control plane
> > traffic, then you either need to (i) define a reserved GMPLS
> > signalling VLAN ID, or (ii) leave it up to the operator to
> > choose a VLAN ID. If you leave it up to the operator to
> > decide what VLAN ID to use, then you need to consider what
> > the implications in the inter-operator case will be, i.e.
> > what VLAN ID range should be used for control plane traffic
> > and what VLAN ID range should be used for user plane traffic.
> >
> > I'm not saying that defining how GMPLS control plane packets
> > are forwarded in the Ethernet data plane will be an issue,
> > simply that this is something that must be addressed to
> > develop interoperable solutions.
> >
> > Regards,
> > Richard
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Heiles Juergen
> > > Sent: 22 July 2005 14:17
> > > To: Loa Andersson; Pär Mattsson
> > > Cc: [email-masked]
> > > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> > >
> > >
> > > GMPLS for SONET/SDH has no impact on the SONET/SDH data plane. It
> > > introduces a control plane for connection setup instead of
> > a network
> > > management based connection setup. GMPLS for Ethernet can
> > work in the
> > > same way. Ethernet as such is cl, but VLANs are setup and GMPLS can
> > > provide a control plane for VLAN setup. The Ethernet data
> > plane is not
> > > changed and MAC address learning and forwarding is still be done
> > > within a VLAN. So no change to the Ethernet data plane. No GMPLS
> > > traffic is introduced, it is still VLAN traffic.
> > > Introducing a dedicated GMPLS label for Ethernet (GMPLS
> > > traffic) goes beyond GMPLS as a control plane technique.
> > >
> > > Regards
> > >
> > > Juergen
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > [mailto:[email-masked]] On
> > > > Behalf Of Loa Andersson
> > > > Sent: Friday, July 22, 2005 12:05 PM
> > > > To: Pär Mattsson
> > > > Cc: [email-masked]
> > > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> > > >
> > > > Per and Dimitri,
> > > >
> > > > I would like to come down stronger than that, for me it is a very
> > > > strong requirement that the same switch can handle both VLANs and
> > > > GMPLs trafic correctly. I can't dsee how that could be
> > done if using
> > > > the VLAN tpid to indicate GMPLS traffic.
> > > >
> > > > /Loa
> > > >
> > > > Pär Mattsson wrote:
> > > > >>hi par, one of the possibilities that has been considered
> > > > to cope with
> > > > >>this requirement is to use a dedicated TPID for the
> > > Ethernet labeled
> > > > >>frames; this would allow differentiated processing with
> > > non-labeled
> > > > >>framesthanks.
> > > > >
> > > > >
> > > > > That seems to make more sence. If that frame is to be sized
> > > > like a 802.1q
> > > > > frame. There is not that much space left to a label. Or is
> > > > the demand to
> > > > > use jumboframes ?
> > > > > Has there been any discussion on labelstacking, and mainly
> > > > where to place
> > > > > the information?
> > > > >
> > > > > Regards.
> > > > > Per
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Loa Andersson
> > > >
> > > > Principal Networking Architect
> > > > Acreo AB                           phone:  +46 8 632 77 14
> > > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > > Kista, Sweden                      email:  [email-masked]
> > > >                                             [email-masked]
> > > >
> > >
> > >
> >
> >
> >
> >
> >

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 22 Jul 2005 20:32:18 -0400

Hi Neil

I concur with Adrian's definition of "IP Control Plane" or "IP-based
Control Plane". 

I think your point is more to the question of where the intelligence to
select the network paths lives. I believe that 
in GMPLS, Path selection and path control is not solely the
responsibility  of "IP-based control plane"  but is enabled by IP
mechanisms to be where it makes sense.   

Regards,
Don 

>-----Original Message----- From: [email-masked] 
>Sent: Friday, July 22, 2005 7:08 PM
>
>
>Hi Neil,
>
>I think John beat me off the blocks here, but...
>
>
>> 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.
>
<snip>

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 22 Jul 2005 18:55:51 -0700

Snipped ...

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

JD:  Over the years I have enjoyed Neil's rants immensely, but I have to
say that this one is a classic.

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 25 Jul 2005 11:14:45 +0200

Hi all,
        this is a very long and very interesting thread but IMHO we're
losing the focus.

W.r.t. the draft-papadimitriou-ccamp-gmpls-ethernet-framework-00 I think
that the ID is useful and I hope that this work progress in the CCAMP.
Moreover I'd like to have some words in the ID on the fact that a GMPLS
enabled Eth TNE can work and interwork also with Eth TNEs that are without
GMPLS control plane.  In the LMP section (section 6.4) there is no mention
about control channel, I'd like to have some words on this.

In general I agree that CP is just a way to automatise and speed-up
operation that can be done via NMS and thus seems to me that the VLAN usage
as GMPLS label is good.  Of course we need to go in deep on this matter but
the idea seems good.

Best regards

Diego

---

From: <[email-masked]>
Date: Mon, 25 Jul 2005 11:06:07 +0100

Hi Igor,

> 
> > 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.
> 
> 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" ? :=)

NH=> To properly answer your question will take me a couple of pages.  I
can help/answer to a fair degree, but if you are really serious about
understanding this stuff better I do think you should seek out the right
folks in operators (not sure you will get all the feedback you need if
you are solely reliant on IETF lists).  Anyway, I'll send you a detailed
reponse off list...and I also note Alan McGuire here has sent you some
stuff off-list on a similar theme wrt to our experiences in BT (quite
compelling IMO).

regads, Neil

---

From: <[email-masked]>
Date: Mon, 25 Jul 2005 12:56:27 +0100

Tom,

G.805 (co) and G.809 (cl) discuss general functional architectural
properties of the data-plane network.  Specific technology ones are then
generated from these.  We've found this stuff invaluable for many
reasons....but its esp crucial if you want sound management information
models.....and for large operators esp this is a very important topic
IMO.   I find it most useful however in a day-day sense (at least in
terms of the principles its based on) to be able to quickly analyse a
technology and spot its strengths/weaknesses.  

Of course a data-plane network can carry traffic or control/management
protocols.  When you are dealing with co mode networks its quite
sensible (and forced in case of the co-cs mode) to have different
data-plane networks working in the same network system.  But see my post
to Igor a while back wrt to what this means when adapting these to be
carried by a lower layer network.  There are rather important network
owenship issues here.

Note also the design (eg for survivability) of the traffic and
control/management data-plane networks can be very different.  And it is
particularly important that the control/management-plane networks only
take their design cues from the duct-graph (you must know about real
physical separacy here if you want to do a good job)

The stuff in SG15 on ASON (various Recs here) discuss control-plane
arch.  And there is a stuff in the M series Recs on management
arch......but I'd look to TMF for this.

If you want to know a good text book, I've still to find anything better
than Reid/Sexton 'Broadband networking'.  Chapters 3 and 4 therein give
an excellent introduction to func arch and what this means for the 3
planes.....but there is lots of other good stuff in here on many topics.
Bit old-hat wrt technologies discussed, but this is not so importnat as
the general networking principles are invariant of technology (provided
one understands the basic modal differences).

regards, neil

> From: Tom Petch [mailto:[email-masked]] 
> Sent: 23 July 2005 16:58
> To: Harrison,N,Neil,IKM1 R
> Cc: [email-masked]
> Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in 
> a l2cs gmpls rnvironment.]
> 
> 
> Neil
> 
> Is there an ITU-T Recommendation that gives an architectural 
> definition of what it means by control plane, data plane, 
> management plane, user plane, traffic dataplane, control data 
> plane etc etc?
> 
> I know what I mean when I use the terms but am not sure I 
> always know what others mean.
> 
> Tom Petch
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, July 23, 2005 2:15 PM
> Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in 
> a l2cs gmpls rnvironment.]
> 
> 
> > JD:  Over the years I have enjoyed Neil's rants immensely, 
> but I have 
> > to say that this one is a classic.
> 
> NH=> Thanks John for the kind words....its good to know 
> you've had at least something to smile about ;-)
> 
> Seriously though, see my updated response to Adrian.  But if 
> you are still struggling to grasp what I mean by the above 
> (out of context
> quote) try this:
> 
> A single cl-ps IP network carrying traffic and everything 
> else (eg public Internet) is very different animal to a co-cs 
> network system where the traffic data-plane network and 
> control/management data-planes network are logically 
> disjoint, ie the role of IP in the latter is importantly 
> different to the role of IP in the former...and let's hope 
> never the 2 shall meet.
> 
> regards, neil
> 
> 
>