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

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

> 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: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: 22 July 2005 19:13
> To: Spencer,R,Richard,XDE73 R; juergen.heiles@siemens.com; 
> loa@pi.se; per@defero.se
> Cc: ccamp@ops.ietf.org
> 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: <richard.spencer@bt.com>
> To: <juergen.heiles@siemens.com>; <loa@pi.se>; <per@defero.se>
> Cc: <ccamp@ops.ietf.org>
> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> > Behalf Of Heiles Juergen
> > Sent: 22 July 2005 14:17
> > To: Loa Andersson; Pär Mattsson
> > Cc: ccamp@ops.ietf.org
> > 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: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On
> > > Behalf Of Loa Andersson
> > > Sent: Friday, July 22, 2005 12:05 PM
> > > To: Pär Mattsson
> > > Cc: ccamp@ops.ietf.org
> > > 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:  loa.andersson@acreo.se
> > >                                             loa@pi.se
> > >
> >
> >
> 
> 
> 
> 
>