[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Friday, July 22, 2005 2:22 PM
> To: adrian@olddog.co.uk; richard.spencer@bt.com;
> juergen.heiles@siemens.com; loa@pi.se; per@defero.se
> Cc: ccamp@ops.ietf.org
> 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: 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
> > > >
> > >
> > >
> >
> >
> >
> >
> >