RE: Frameformat in a l2cs gmpls rnvironment.

[Heiles Juergen <juergen.heiles@siemens.com>]

Hi Dimitri,

 

what I described is the straight forward approach like it is used for SONET/SDH or OTN. A pure control plane approach for setup of connectivity. You could even keep the restriction of a domain local VLAN ID as defined by IEEE. It is "just" a restriction of matrix connectivity like some older SONET/SDH equipment also has (e.g. no time slot interchange in a ring). So it would have no major impact on 802.1d except for the definition of a control plane communications channel as mentioned by Richard.

In case we make any changes to the data plane behavior like disabling of MAC address learning and MAC address based forwarding and introduction of a dedicated label we introduce a new layer network like MPLS did for IP. This has much wider impact and should be carefully considered.

 

Regards

 

Juergen

 

---

From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Friday, July 22, 2005 4:03 PM
To: Heiles Juergen
Cc: Loa Andersson; Par Mattsson; ccamp@ops.ietf.org
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

hi juergen,

if well understand your point of view, you would be in favor of setting up path without introducing any specific indication in the data plane Ethernet frame flow

more precisely, once the "logical path" is setup using the control plane, the forwarding behaviour would remain unchanged from legacy Ethernet behaviour (i.e MAC address learning and forwarding based on MAC DA) in this case, the control plane function replaces the VLAN id configuration performed today manually on a per interface basis ? - please confirm

now, i would interested to know what in your view would be the role of 802.1d and related in this context (also there are several levels of interaction possible here)

Heiles Juergen <juergen.heiles@siemens.com>
Sent by: owner-ccamp@ops.ietf.org
07/22/2005 15:17 ZE2

To: Loa Andersson <loa@pi.se>, Pär Mattsson <per@defero.se>
cc: ccamp@ops.ietf.org
bcc:
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
>