Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Tue, 26 Jul 2005 23:24:47 -0700

Dimitri,
 
By "existing Ethernet switches", I mean Ethernet switches based on
current approved IEEE 802 .1Q/.1D standards and not the hypothetical
switches with TBD forwarding characteristics. Anyway, if the objective
is to use RSVP-TE with "existing Ethernet switches", you can do that
easily by designating a VLAN or (set of VLANs) for RSVP-TE traffic and
support both EoMPLS and native bridged traffic on a single trunk. There
is some overhead with such encapsulation but the benefit of it is that
it works now. If we want to do it through some other means (such as MAC
address translation), then the benefit of such approach is not clear to
me; however, the disadvantages are very clear :-) Anyway, I'll look
forward to more discussions during and after the meeting next week.
 
Cheers,
Ali

________________________________

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Tuesday, July 26, 2005 4:21 PM
	To: Ali Sajassi (sajassi)
	Cc: CHO, JAI HYUNG; Heiles Juergen; [email-masked];
[email-masked]
	Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/
GMPLS Ethernet

	ali

	to be clear here you are hanging on using the term "existing
Ethernet switches" while the document that has been at the source of the
discussion does not state "GMPLS must be deployable on existing Ethernet
switches" this may be the case but there are limitations (and there are
perfectly well understood, don't worry) beside this you should also tell
us what do you exactly mean with the term "existing" - but this is a
side issue -

	this said, this does NOT mean that a GMPLS Ethernet switch
(either existing or even "extended") would need to support a new
Ethernet 802.3 frame forwarding paradigm, the difference is subtle but
has to be underlined

	note: there is a slot of 20 minutes during the next CCAMP WG
meeting where this document and all related issues will be heavily
discussed ... so i welcome you to join the festivities ;-)

	thanks,

	- dimitri.

	"Ali Sajassi \(sajassi\)" <[email-masked]>
	Sent by: [email-masked]
	07/25/2005 16:13 MST
	
	To: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen"
<[email-masked]>, <[email-masked]>
	cc: <[email-masked]>
	bcc: 
	Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/
GMPLS Ethernet

	Jaihyung,
	
	It seems to me that your primary objective is to use the
existing
	Ethernet switches with new control plane (GMPLS) to setup TE
paths for
	different applications. And you mentioned three approaches for
doing
	this in your email. However, all three of them have issues and
are not
	viable. Lets go over them ...
	
	>
	> In below mail, I discussed about three proposed approaches.
	>
	>
	> 1. using VLAN tag as it is for L2 label encoding.
	
	As you know this approach has scalability issue and you are
limited to
	4K services in the network and if you try to use the upcoming
IEEE
	802.1ad standard to make VLANs, interface specific, then you
will need
	new switches and not existing Ethernet switches. Even if you use
these
	newer switches, you will still be limited to 4K services per
interface
	and it would defeat the objective of using existing switches.
	
	>
	> 2. defining new protocol ID (TPID) and borrow VLAN tag format,
	> ?or extended VLAN tag to implement label swapping.
	>
	
	This approach requires new data plane functionality to be
implemented
	(which defeats the objective of using existing switches).
	
	> 3. use lower 3 bytes of MAC address for L2 label encoding.
	>
	
	This approach has several issues:
	1) how does MAC addresses get distributed among the bridges ?
How does
	this distribution works during a link or node failure ? How does
it
	recover from a link or node failure ?
	
	2) Will you assign a separate provider MAC for each customer
MAC. If so,
	then how do you address MAC scalability. If not, then how do you
take
	care of 1-to-N mapping between provider MAC address and customer
MAC
	addresses and how do you handle multipoint connections.
	
	3) how do handle customer FCS retention when doing this MAC
translation
	stuff ??
	
	>
	> 802.1Q bridge forwards Ethernet frames using two dataplane
tables
	> - MAC forwarding table and VLAN forwarding table.
	> Bridge control protocols, such as GARP, GVRP, GMRP,
	> manipulate one of the two dataplane entities.
	
	This is not correct. Bridges don't have different databases for
MAC
	forwarding and VLAN forwarding. They have filtering datebase(s)
with
	corresponding IDs (FIDs). VLAN IDs get mapped to FIDs based on
operation
	mode (IVL versus SVL). Then once a filtering database is
identified,
	then a MAC address lookup is performed for forwarding. Bridge
control
	protocols use a designated MAC addressed and based on these MAC
	addressed, the bridge knows how to process the frame.
	
	>
	> Similarly, option 1 and 3 are about which one of two
	> dataplane entities
	> GMPLS protocol should control on behalf of bridge control
protocols.
	> The two proposals do not intend to modify bridge behavior
	> seriously, such as MAC learning, aging, filtering.
	> Therefore, the approaches 1 and 3 are in the scope of CCAMP.
	
	If that's the intention, you may find out soon you get more than
what
	you asked for :-)
	
	>
	> (% note however, I would regard implementing label swapping
	> function is acceptable change considering the Internal
Sublayer
	> design of 802.1D bridge.)
	>
	
	The only way of doing this is using VID translation table
specified in
	IEEE 802.1ad which requires new data-plane functionality and
thus
	existing bridges cannot be used !!
	
	Also if going the route of tag swapping, you may consider using
IEEE
	802.1ah. As the editor of .1ah, I can go over the details when I
get a
	chance.
	
	>
	> However, option 2 is about what TPID code we will
	> choose to implement new switching function.
	> The switch of this implementation should have new hardware
	> design in addition to normal bride hardware.
	> I think such proposal as option 2 is out of CCAMP scope.
	
	Yes.
	
	>
	> Overall objective is improving scalability, traffic
engineering (TE)
	> characteristics of 802.1 bridge that it can be reliable,
manageable
	> enough to replace some core routers.
	
	Easier said than done :-)
	
	> The switching technique you mentioned above, such as
	> Ethernet over MPLS as defined by PWE3 and L2VPN,
	> are all actually router based technology, however this
	> work is based on simple bridge architecture.
	> Cost-effectiveness is the key differentiator.
	>
	
	The devils are in the details and once you worked out the
details, you
	will see the issues.
	
	>
	> In access or enterprise network, capability of providing
end-to-end
	> L2-LSP will enable service providers policing, measuring,
charging
	> application flows using Ethernet based network. This will
eventually
	> improve income structure and introduce new session based
commercial
	> service. I have been discussing this aspect in mail thread of
	> title 'End-to-end L2-LSP'.  Please read the mail thread and
comment
	> on the discussion.
	>
	>
	> >You mentioned to use the MAC address or part of it as a
label.
	> >The TRILL working group is defining shortest path routing
	> for Ethernet.
	> >How would this fit together?
	>
	>
	> TRILL employs new encapsulation layer outside of Ethernet
frames.
	> However in my proposal of option-3, I simply use the Ethernet
header
	> to encode GMPLS label.
	>
	> The overall format of rbridge is
	> [Ethernet][r-tag][Ethernet][ data..]
	> It is not LSP based technology but a connectionless routing
bridge.
	> TTL count is very important in rbridge because frames are
routed
	> hop-by-hop and it may loop.
	>
	> Whereas in option-3 above, Ethernet frames that have certain
	> OUI prefix in MAC address are forwarded via a path that
	> GMPLS protocol has configured on MAC forwarding table.
	>
	
	How does the redundancy work in here. Are you using bridge
protocol in
	conjunction with GMPLS protocol. If you do, then there are bunch
of
	issues. If you don't, then what is it used and how does it
interact with
	bridging protocols ??
	
	-Ali

	>
	> Thanks
	>
	> Jaihyung
	>
	>
	>
	> -----?? ???-----
	> ?? ??: "Heiles Juergen" <[email-masked]>
	> ?? ??: 2005-07-25 ?? 6:44:34
	> ?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles
	> Juergen" <[email-masked]>, "[email-masked]"
	> <[email-masked]>
	> ??: "[email-masked]" <[email-masked]>
	> ??: RE: Frameformat in a l2cs gmpls rnvironment.
	>
	>
	>
	>
	>
	>
	> Dear Jaihyung,
	>
	> you mention several options that could be used as a label.
	> Most of them have strong impacts on the data plane and
	> introduce new layer networks. Is this in the scope of CCAMP?
	> What is the goal, to introduce a control plane for a existing
	> L2 technology or introduce a new L2 technology? What would be
	> the benefit of such a new L2 co switching technology compared
	> to Ethernet over MPLS as defined by PWE3 and L2VPN?
	> You mentioned to use the MAC address or part of it as a
	> label. The TRILL working group is defining shortest path
	> routing for Ethernet. How would this fit together?
	>
	>
	> Regards
	>
	> Juergen
	>
	>
	>
	>
	>
	> > -----Original Message-----
	> > From: CHO, JAI HYUNG [mailto:[email-masked]]
	> > Sent: Saturday, July 23, 2005 6:19 AM
	> > To: Heiles Juergen; [email-masked]
	> > Cc: [email-masked]
	> > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
	> >
	> >
	> > Dear Juergen, Par and all,
	> >
	> > The proposed framework of L2SC was not intended to suggest
	> > any specific solution. It is still an open question.
	> > As Adrian noted, it only aims to present requirements
	> > as in scenarios that may drive people toward next step in
many
	> > viable solutions.
	> >
	> > In fact, there are other options we may also consider for L2
	> > label encoding.
	> > IEEE 802.1 Ethernet bridges forward frames based on 48bits
of
	> > MAC address,
	> > and additionally using VLAN tag.
	> >
	> > When the purpose of GMPLS control over Ethernet is not to
	> > create new dataplane
	> > but to utilize IEEE 802.1 bridge architecture, we may
	> consider using
	> > one of the two forwarding methods, MAC forwarding or VLAN
	> forwarding.
	> > (and perhaps any other combination of fields in MAC, but
I'll
	> > not discuss it)
	> >
	> > Use of VLAN ID for label encoding may automate VLAN
configuration
	> > using IP protocols. However, GMPLS protocol cannot use the
	> > field exclusively
	> > because public/private operators already use VLAN for
various
	> > purpose.
	> > There is a potential conflict with existing use of VLAN and
	> > GMPLS use of VLAN label.
	> > Furthermore, scalability of VLAN ID has been frequently
noted
	> > as weakness
	> > because the size of VLAN ID is at most 4096 (12bit).
	> >
	> > The scalability may be improved if the scope of VLAN label
is
	> > confined to
	> > link-local, and some additional swapping function of VLAN ID
	> > is introduced in
	> > Internal Sublayer [802.1D] of GMPLS implemented switch.
	> > However, this will only be effective when the configuration
	> > of network
	> > is mesh structure that multiple LSP paths exist. If the
	> > configuration of network
	> > is star or tree shape, as normal configuration of access
network,
	> > LSPs concentrate in root node and total number of
	> > LSPs that the network can hold still be limited by available
	> > label space
	> > at a few root links.
	> >
	> > For these reasons, I do not think any form of VLAN ID label
is
	> > an appropriate choice for layer-2 label encoding.
	> >
	> > There are some other proposals assuming new assignment of
Ethernet
	> > Length/Type value (e.g. new TPID in VLAN tag) and
re-definition of
	> > information fields placed between 802.3 MAC header and IP
packet.
	> > In this case, only the format of VLAN tag or extended VLAN
tag
	> > is borrowed, however, inside the switching hardware, the
	> > filter and relay,
	> > etc. are totally different new dataplane switch.
	> >
	> > I do not see such approach is a GMPLS implementation for
Ethernet
	> > because the core switching technique is not 802.1 Ethernet
	> > bridge at all.
	> >
	> > The other option we may consider is using MAC address filed
	> as below.
	> >
	> >
	> > +-------+-------+-------+-------+-------+-------+
	> > | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte |
	> > +-------+-------+-------+-------+-------+-------+
	> > +-----------------------+-----------------------+
	> > |  OUI Prefix (=GMPLS)  |   DA-label (24bit)    |
	> > +-----------------------+-----------------------+
	> > |  OUI Prefix (=GMPLS)  |   SA-label (24bit)    |
	> > +---------------+-------+-----------------------+
	> > | Length/Type   |
	> > +---------------+
	> >
	> >
	> > IEEE is designated by the ISO Council to act as the
	> > registration authority
	> > for the higher three-octet of OUI number in the MAC address
	> > to be used by manufacturer. Ethernet manufacturer may
generate
	> > global unique MAC address using the OUI prefix and address
block of
	> > lower three-octet (24bit). Taking advantage of the
	> addressing scheme,
	> > GMPLS may use the lower three-octet exclusively if a unique
	> > OUI number
	> > is reserved for the protocol. With this labeling scheme,
GMPLS will
	> > control MAC forwarding entry, not VLAN table.
	> >
	> > All Ethernet frames controlled by GMPLS will have identical
	> > OUI number
	> > that they can easily be distinguished from other Ethernet
frames.
	> > In principle, the label lookup hardware is identical to MAC
lookup
	> > hardware in this labeling scheme. Therefore GMPLS
implemented
	> > switch may still function as normal Ethernet bridge to the
frames
	> > that OUI number is not GMPLS. This also facilitates GMPLS
	> implemented
	> > switches being deployed in operating Ethernet with minimum
	> > service disruption.
	> >
	> > Note also that above proposed label encoding method is
transparent
	> > to the use of Ethernet Length/Type field. End-user device
may use
	> > the Length/Type field as defined in IEEE 802.3 protocol.
	> > It also allows network operators configure VLAN for their
own
	> > purpose.
	> > When IEEE 802.1p is used in conjunction with L2-LSP, the
priority
	> > field of VLAN tag can also be used for imposing consistent
TE
	> > policy in
	> > legacy switches and GMPLS switches.
	> >
	> > Any way, my conclusion is, there are other options we may
consider,
	> > and this issue is still open to discuss.
	> >
	> > Thanks,
	> >
	> > Sincerely,
	> >
	> > Jaihyung
	> >
	> >
	> >
	> >
	> >
	> > -----?? ???-----
	> > ?? ??: "Heiles Juergen" <[email-masked]>
	> > ?? ??: 2005-07-22 ?? 10:23:43
	> > ?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]"
	> > <[email-masked]>
	> > ??: "[email-masked]" <[email-masked]>, "[email-masked]"
	> > <[email-masked]>
	> > ??: RE: Frameformat in a l2cs gmpls rnvironment.
	> >
	> >
	> >
	> >
	> >
	> >
	> > 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: [email-masked]
	> > > [mailto:[email-masked]] On Behalf Of Loa
Andersson
	> > > Sent: Friday, July 22, 2005 2:53 PM
	> > > To: [email-masked]
	> > > Cc: [email-masked]; [email-masked]
	> > > 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
	> > >
	> > > [email-masked] 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: [email-masked]
	> > [mailto:[email-masked]]On
	> > > >>Behalf Of Par Mattsson
	> > > >>Sent: 22 July 2005 11:42
	> > > >>To: Loa Andersson
	> > > >>Cc: [email-masked]
	> > > >>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
	> > > >>>
	> > > >>>Par 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:
	> > [email-masked]
	> > > >>>                                            [email-masked]
	> > > >>>
	> > > >>
	> > > >>
	> > > >>
	> > > >
	> > >
	> > >
	> > > --
	> > > Loa Andersson
	> > >
	> > > Principal Networking Architect
	> > > Acreo AB                           phone:  +46 8 632 77 14
	> > > Isafjordsgatan 22                  mobile: +46 739 81 21
64
	> > > Kista, Sweden                      email:
[email-masked]
	> > >                                             [email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Wed, 27 Jul 2005 12:44:51 +0200

Ali,

yes - we can make a solution based on designated vlans "work", but if
we do that we will have serious scaling issues

i don't know if we are ready to start the discussion on solution, but
we seems to do that anyway ;)

there is a way for us to get a tpid from IEEE, we could specify the
behavior of switches on that tpid

my take that we shouldn't do that without involving ieee, but on the
other it is normally quite easy to work with them

but again we need to undestand requirements first

/Loa

Ali Sajassi (sajassi) wrote:
> easily by designating a VLAN or (set of VLANs) for RSVP-TE traffic 
> and support both EoMPLS and native bridged traffic on a 
> single trunk. There is some overhead with such encapsulation but the 
> benefit of it is that it works now. If we want to do it through some 
> other means (such as MAC address translation), then the benefit of such 
> approach is not clear to me; however, the disadvantages are very clear 
> :-) Anyway, I'll look forward to more discussions during and after the 
> meeting next week.
>  
> Cheers,
> Ali
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked]
>     *Sent:* Tuesday, July 26, 2005 4:21 PM
>     *To:* Ali Sajassi (sajassi)
>     *Cc:* CHO, JAI HYUNG; Heiles Juergen; [email-masked]; [email-masked]
>     *Subject:* RE: Frameformat in a l2cs gmpls rnvironment - Issues w/
>     GMPLS Ethernet
> 
>     ali
> 
>     Ethernet switches" while the document that has been at the source of
>     the discussion does not state "GMPLS must be deployable on existing
>     Ethernet switches" this may be the case but there are limitations
>     (and there are perfectly well understood, don't worry) beside this
>     you should also tell us what do you exactly mean with the term
>     "existing" - but this is a side issue -
> 
>     this said, this does NOT mean that a GMPLS Ethernet switch (either
>     existing or even "extended") would need to support a new Ethernet
>     802.3 frame forwarding paradigm, the difference is subtle but has to
>     be underlined
> 
>     note: there is a slot of 20 minutes during the next CCAMP WG meeting
>     where this document and all related issues will be heavily discussed
>     ... so i welcome you to join the festivities ;-)
> 
>     thanks,
> 
>     - dimitri.
> 
>      
> 
>     *"Ali Sajassi \(sajassi\)" <[email-masked]>*
>     It seems to me that your primary objective is to use the existing
>     Ethernet switches with new control plane (GMPLS) to setup TE paths for
>     different applications. And you mentioned three approaches for doing
>     this in your email. However, all three of them have issues and are not
>     As you know this approach has scalability issue and you are limited to
>     4K services in the network and if you try to use the upcoming IEEE
>     802.1ad standard to make VLANs, interface specific, then you will need
>     new switches and not existing Ethernet switches. Even if you use these
>     newer switches, you will still be limited to 4K services per interface
>     This approach requires new data plane functionality to be implemented
>     1) how does MAC addresses get distributed among the bridges ? How does
>     this distribution works during a link or node failure ? How does it
>     2) Will you assign a separate provider MAC for each customer MAC. If so,
>     then how do you address MAC scalability. If not, then how do you take
>     care of 1-to-N mapping between provider MAC address and customer MAC
>     3) how do handle customer FCS retention when doing this MAC translation
>     stuff ??
> 
>      >
>      > 802.1Q bridge forwards Ethernet frames using two dataplane tables
>     This is not correct. Bridges don't have different databases for MAC
>     forwarding and VLAN forwarding. They have filtering datebase(s) with
>     corresponding IDs (FIDs). VLAN IDs get mapped to FIDs based on operation
>     mode (IVL versus SVL). Then once a filtering database is identified,
>     then a MAC address lookup is performed for forwarding. Bridge control
>      > GMPLS protocol should control on behalf of bridge control protocols.
>     If that's the intention, you may find out soon you get more than what
>     you asked for :-)
> 
>      >
>      > function is acceptable change considering the Internal Sublayer
>     The only way of doing this is using VID translation table specified in
>     IEEE 802.1ad which requires new data-plane functionality and thus
>     Also if going the route of tag swapping, you may consider using IEEE
>     802.1ah. As the editor of .1ah, I can go over the details when I get a
>     chance.
> 
>      >
>      > Overall objective is improving scalability, traffic engineering (TE)
>      > characteristics of 802.1 bridge that it can be reliable, manageable
>     The devils are in the details and once you worked out the details, you
>     will see the issues.
> 
>      >
>      > In access or enterprise network, capability of providing end-to-end
>      > L2-LSP will enable service providers policing, measuring, charging
>      > application flows using Ethernet based network. This will eventually
>      > improve income structure and introduce new session based commercial
>      > title 'End-to-end L2-LSP'.  Please read the mail thread and comment
>      > on the discussion.
>      >
>      >
>      > >You mentioned to use the MAC address or part of it as a label.
>      > TRILL employs new encapsulation layer outside of Ethernet frames.
>      > However in my proposal of option-3, I simply use the Ethernet header
>      > to encode GMPLS label.
>      >
>      > It is not LSP based technology but a connectionless routing bridge.
>      > TTL count is very important in rbridge because frames are routed
>     How does the redundancy work in here. Are you using bridge protocol in
>     conjunction with GMPLS protocol. If you do, then there are bunch of
>     issues. If you don't, then what is it used and how does it interact with
>     bridging protocols ??
> 
>     -Ali
> 
> 
>      >
>      > Thanks
>      >
>      > Jaihyung
>      >
>      >
>      >
>      > -----?? ???-----
>      > > as in scenarios that may drive people toward next step in many
>      > > viable solutions.
>      > >
>      > > IEEE 802.1 Ethernet bridges forward frames based on 48bits of
>      > > MAC address,
>      > > (and perhaps any other combination of fields in MAC, but I'll
>      > > not discuss it)
>      > >
>      > > Use of VLAN ID for label encoding may automate VLAN configuration
>      > > because public/private operators already use VLAN for various
>      > > purpose.
>      > > Furthermore, scalability of VLAN ID has been frequently noted
>      > > as weakness
>      > > The scalability may be improved if the scope of VLAN label is
>      > > confined to
>      > > is star or tree shape, as normal configuration of access network,
>      > > For these reasons, I do not think any form of VLAN ID label is
>      > > There are some other proposals assuming new assignment of Ethernet
>      > > Length/Type value (e.g. new TPID in VLAN tag) and re-definition of
>      > > information fields placed between 802.3 MAC header and IP packet.
>      > > In this case, only the format of VLAN tag or extended VLAN tag
>      > > I do not see such approach is a GMPLS implementation for Ethernet
>      > > to be used by manufacturer. Ethernet manufacturer may generate
>      > > global unique MAC address using the OUI prefix and address block of
>      > > is reserved for the protocol. With this labeling scheme, GMPLS will
>      > > that they can easily be distinguished from other Ethernet frames.
>      > > In principle, the label lookup hardware is identical to MAC lookup
>      > > hardware in this labeling scheme. Therefore GMPLS implemented
>      > > switch may still function as normal Ethernet bridge to the frames
>      > > Note also that above proposed label encoding method is transparent
>      > > to the use of Ethernet Length/Type field. End-user device may use
>      > > It also allows network operators configure VLAN for their own
>      > > purpose.
>      > > When IEEE 802.1p is used in conjunction with L2-LSP, the priority
>      > > field of VLAN tag can also be used for imposing consistent TE
>      > > policy in
>      > > Any way, my conclusion is, there are other options we may consider,
>      > > I interpret the ID as a proposal to use GMPLS for VLAN setup.
>      > > plane and GMPLS at the control plane. The question is how and
>      > > > [mailto:[email-masked]] On Behalf Of Loa Andersson
>      > > > 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
>      > > > Do you have any comment on the requirement to run both VLANs and
>      > > > > Regardless of whether or not a switch is directly connected
>      > > >  > each other, a data plane for control traffic must be present.
>      > > >  > 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
>      > > >  > think extending L2-LSPs into the enterprise/home network is
>      > > >  > normal Ethernet Mac address switching anyway. Instead you will
>      > > >  > (e.g. a gateway router) may exist for different services/flows
>      > > > >>>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
>      > > > >>If you ever want that same switch to handle traffic for a
>      > > directly
>      > > > >>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
>      > > > >>>
>      > > > >>>Par Mattsson wrote:
>      > > > >>>
>      > > > >>>>>hi par, one of the possibilities that has been considered
>      > > > >>
>      > > > >>to cope with
>      > > > >>
>      > > > >>>>>frames; this would allow differentiated processing with
>      > > > non-labeled
>      > > > >>>>>framesthanks.
>      > > > >>>>
>      > > > >>>>
>      > > > >>>>frame. There is not that much space left to a label. Or is
>      > > > >>
>      > > > >>the demand to
>      > > > >>
>      > > > >>>>use jumboframes ?
>      > > > >>>Isafjordsgatan 22                  mobile: +46 739 81 21 64
>      > > > >>>Kista, Sweden                      email:
>      > > [email-masked]
>      > > > >>>                                            [email-masked]
>      > > > >>>
>      > > > >>
>      > > > >>
>      > > > >>
>      > > > >
>      > > >
>      > > >
>      > > > --
>      > > > Loa Andersson
>      > > >
>      > > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
>      > > > Kista, Sweden                      email:  [email-masked]
>      > > >                                             [email-masked]
>      > > >
>      > >
>      > >
>      > >
>      > >
>      >
>      >
>      >
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]