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

[<richard.spencer@bt.com>]

Adrian,

I don't understand why you have renamed the thread "Ethernet Control Plane" in response to my email. I haven't even mentioned an Ethernet Control Plane.

I'm quite aware that GMPLS uses IP labelled control protocol packets and I haven't suggested removing IP and just using Ethernet. In fact, I would have thought my analogy with how a management VLAN is used today (e.g. for ICMP ping and telnet) would have demonstrated that.

I am simply saying that for two GMPLS peers to send (IP labelled) control protocol packets to each other, they must agree to encapsulate the packets using either untagged Ethernet frames or using tagged Ethernet frames with a common VLAN ID. Again, I'm not saying this is an issue, just something that needs to be considered. Switches are not routers and normally only send/receive locally addressed IP packets via the management VLAN, e.g. to ping between two directly connected switches the interfaces they are connected via must both be configured to be in the same management VLAN.

Regards,
Richard

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> 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
> > >
> >
> >
> 
> 
> 
>