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

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Wed, 27 Jul 2005 10:51:38 -0700

Loa,

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

I think you might have misinterpreted what I was saying. I was talking
about using MPLS encap first and then have MPLS traffic over its
designated VLAN(s). All the GMPLS traffic can be carried over a single
VLAN or you can have more than one for load balancing purposes. And thus
there shouldn't be any scalability issues.
 
> 
> i don't know if we are ready to start the discussion on 
> solution, but we seems to do that anyway ;)
> 
Apparently :-)

> 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
> 

If interested one can come and discuss it during next 802.1 group (which
is the architecture group for IEEE bridges) meeting.

> but again we need to undestand requirements first
> 

Completely agree. 

-Ali

> /Loa
> 
> Ali Sajassi (sajassi) wrote:
> > 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]
> >      > > >
> >      > >
> >      > >
> >      > >
> >      > >
> >      >
> >      >
> >      >
> > 
> 
> 
> --
> 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: Thu, 28 Jul 2005 13:38:52 +0200

> Loa,
Ali,

I don't parse the paragraph below. If you said "All the MPLS traffic
can be carried..." I would understand it. But, then we have done
that for the last 6 years.
We were talking about extending the GMPLS control plane to control
Ethernet traffic, and into a MRN (gosh I hate that name ;))
architecture.
My take here is that we need to cooperate with IEEE to do this, since
in my opinion, we need to discuss the forwarding plane.

/Loa

-- 
Loa Andersson