RE: Frameformat in a l2cs gmpls rnvironment.

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

Loa,

I interpret the ID as a proposal to use GMPLS for VLAN setup. So GMPLS and VLAN to not compete. The VLAN is at the data plane and GMPLS at the control plane. The question is how and should different control plane techniques like GMPLS and (GVRP and STB) work together?

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 2:53 PM
> To: richard.spencer@bt.com
> Cc: per@defero.se; ccamp@ops.ietf.org
> Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> 
> Richard,
> 
> I agree to most of this. Since we have doubts about the viability
> of taking GMPLS all the way to end-user or enterprise I think it
> would be good, from a wg perspective, if we agreed to solve the
> core network problems first.
> 
> Do you have any comment on the requirement to run both VLANs and
> GMPLS on the same switch?
> 
> /Loa
> 
> richard.spencer@bt.com wrote:
> > Regardless of whether or not a switch is directly connected
>  > to hosts, it must be able to forward packets using the 
> connectionless
>  > Ethernet data plane. This is due to the fundamental 
> requirement that
>  > for GMPLS switches to be able to exchange control information with
>  > each other, a data plane for control traffic must be present.
>  > This is akin to using the IP data plane for MPLS signalling in an
>  > IP/MPLS network. An alternative would be to use a static reserved
>  > L2-LSP for control traffic in the same way that reserved VPI/VCIs
>  > are used for PNNI signalling in ATM.
> > 
> > Regarding connecting hosts to GMPLS switches, I personally don't 
>  > think extending L2-LSPs into the enterprise/home network is
>  > commercially viable. However, if you do want to use GMPLS switches
>  > in the home/enterprise network and for some reason don't want to
>  > extend L2-LSPs down to the host then you will not be performing
>  > normal Ethernet Mac address switching anyway. Instead you will
>  > need some kind of policy on the switch that maps connectionless
>  > Ethernet packets (e.g. based on MAC src/dest, 802.1p, VLAN) to a
>  > L2-LSP. This is because multiple L2-LSPs to the same destination
>  > (e.g. a gateway router) may exist for different services/flows
>  > (e.g. video download, VoIP call, etc.).
> > 
> > Regards,
> > Richard
> > 
> > 
> >>-----Original Message-----
> >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> >>Behalf Of Pär Mattsson
> >>Sent: 22 July 2005 11:42
> >>To: Loa Andersson
> >>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.
> >>
> >>If you ever want that same switch to handle traffic for a directly
> >>connected  host (not to uncommen) you would want that to use normal
> >>ethernet macaddress switching. So of course you do not want 
> to have to
> >>choose between vlan and gmpls, you would want both at the same time.
> >>
> >>/per
> >>
> >>
> >>
> >>>/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
> >>>
> >>
> >>
> >>
> > 
> 
> 
> -- 
> 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
>