GMPLS controlled Ethernet Label Switching (GELS) BOF - Meeting Minutes

Tuesday, November 8th from 1510-1710 (Afternoon Session II)
====================================

CHAIRS:
------

Loa Andersson 
Dimitri Papadimitriou 

MINUTES: 
-------
Martin Vigoureux and Giles Heron

AGENDA:
------

o) Welcome, Administrativia and Agenda Bashing - 5min

Administrativa: 
- blue sheets
- note takers

Dimitri: do we have IAB presence in the room - no ?

Alex: well... that's all right

Dimitri: do we have a jabber scribe volunteer - no

Agenda bashing: no comment

-----

o) Objectives and Scope - 10min

Dimitri:
- determine community interest
- gauge if support for this work within IETF community
- highlight and discuss potential interaction with other SDOs
- discuss GMPLS control plane operations

Alex:
- Background reminder
  . re-state reason this is not taking place in CCAMP
  . number of CCAMP items to be well manageable and make sure not too much work
- BoF objectives
  . whether we have a good agreement on problem definition
  . the direction of the protocol work
  . judgment whether there is enough support to do this work within the IETF

Dimitri:

- Scope and basic concepts
  . Ethernet LER, Ethernet LSR, basic operations, setup, release for P2P TE-LSP

- Major work item: Ethernet Label space definition
 
- Some work has been IDed to be out of the scope:
  . GMPLS to the customer/host
  . Mobile and wireless networks
  . TE and non TE MP LSPs

- Concerning the so-called changes or operations on the data plane,
  initiate discussions with the IEEE to see what's possible or not.

-----

o) Data Plane and Cooperation with IEEE - 20min

Data plane operations

One of main work is around the label space definition.
- scope (local/global)
- encoding (shim/frame)

Floor will be left to present another alternative which is not included
in the BoF preparation document as it came afterwards.

Hoping to find a consensus (on which alternative to select) and progress the work

Presentation of the alternatives for label encoding as described in BoF preparation document

1) MAC-shim-MAC

Mark Townsley: What does "not really Ethernet" means ?

Dimitri: you are not processing information contained within Ethernet header.

Mark: Why is that a con ?

Dimitri: would not be a true Ethernet operation

2) Proprietary MAC address

Use OUI plus label. Need to rewrite source/dest MAC as frame enters/leaves network.

3) S-VID

Supported by most switches, but label space is small and issues with interop with non-GMPLS switches. Making use of the S-VID translation might be a way to realize this approach

4) New (TPID) Ethertype 

So dedicated space for label switching (still 12 bits)

- Identified Data Plane Requirements

. Ethernet MAC frame structure must be left unchanged i.e. composed by Ethernet MAC frame header, a Payload and an FCS  
. Ethernet MAC frame header must remain structured such as to include the MAC_DA, MAC_SA one or more TAGs and the EtherType  
. Ethernet TAG must still include a TPID (TAG Protocol ID) and a TCI (TAG Control Information) 
. Physical medium over which Ethernet labeled frames could be transmitted are left unchanged and be forward compatible with IEEE 802.3
. MAC address space, size (6 bytes), format and semantic are left unchanged and must still support unicast, multicast and broadcast format and semantic
. Ethernet label format and switching must be such as to leave IEEE 802.1ag CFM operations independent
. MTU size: the size of the Ethernet labeled frame falls into the revision of the IEEE P802.3as Ethernet Frame Expansion

- IEEE 802.1 overview (Paul Condong - Vice-chair IEEE 802.1)

Presentation of IEEE 802.1 active projects
Capital letters: stand-alone document
Little letters: part of another document (extention to) interworking projects:
. 802.1ad (QinQ, vlan stacking) is an update to 802.1Q.
. 802.1ag is OAM (L2 ping/traceroute) - focused on provider networks.
. 802.1ah is scheme for interconnecting provider networks (additional Ethernet header for   bridged packets to scale the address space when bridging across multiple providers).
. 802.1aj is a media extender (passes diagnostic info)
. 802.1ak (MRP) is update to GVRP, GMRP. One frame per VLAN/registration was bad. So this   lets you do multiple updates in one packet.
. 802.1ap is MIB in IEEE. Any new project that needs a MIB will be responsible for defining   that MIB, so won't need a parallel group in IETF as in the past.
. 802.1aq is scheme for shortest path bridging using spanning trees.
  security projects:
. 802.1AE is encryption above MAC layer.  above MAC layer so not just Ethernet MAC, but not   generally for wireless MACs - as wireless MACs have their own encryption.
  etc. IEEE project responsible for its MIBs definition.
. 802.1ad is in sponsor ballot, equivalent to IESG Last Call. Full STD published anytime
. 802.1AE also in sponsor ballot.

Kireeti Kompella: color code (red and black) significance ?

Paul Condon: nothing particular, due to cut and paste

Kireeti: Are you going to liaise these to us or make these available to us ?

Paul: if and when there is a WG and there is a liaison between this WG and 802.1
the documents will be available. Even if your are not voting member comments to documents will be answered.

Dimitri: I put a list of documents relevant to this topic. I you can make them available this would be appreciated.

-----

o) Control Plane and Cooperation with IETF WGs - 15min

- Identified Generic Requirements = applicable independently of the label space definition and processing:
. Re-/use TE methods defined for G/MPLS
. Re-/use recovery methods defined for G/MPLS 
. GMPLS is based on the IP routing and addressing models, in part. IPv4 and/or IPv6 addresses are used to identify L2SC interfaces incl. Scalability enhancements to addressing (e.g. unnumbered and bundled links) must be re-usable 
. GMPLS control plane information exchange between adjacent Ethernet LSRs and control plane information processing must be independent of the IP control channel implementation
. Control plane resilience mechanisms defined for GMPLS control plane (e.g.  RSVP engine graceful restart) must be re-usable for Ethernet LSR

Alex: Could you elaborate (point 4) ?

Dimitri: How IP packets exchanged between controllers ? Running on native Ethernet but other ways possible. So GMPLS CP really independent on how control channels implemented.

Alex: So basically what you say is that we need continue the GMPLS way of doing things
where the CP is decoupled from the data plane

Dimitri: yes, if possible.

- Link Discovery 
. Aggregation of multiple data links into a single TE Link and synchronize their properties  . Verify data links physical connectivity and verify the mapping of the Interface ID to Link   ID and their local-remote associations 
. Optionally, fault management may be provided to suppress alarms and localize failures.  
  Extensions to LMP may be required  

- Routing Advertisement and Traffic Engineering 
. Routing instance should treat the broadcast point-to-point control channel between adjacent LSRs as a point-to-point circuit   
. Exchange of reachability information
. Exchange of traffic engineering information

- Signaling: GMPLS RSVP-TE Feature Set
. Ethernet Traffic Parameters 
. Ethernet Label Request 
. Ethernet Label: L2 labels are context sensitive interpretation of the received label depends on the type of the link [X,L2SC], [L2SC,L2SC], [L2SC,X] over which the label is used. The received label MUST be interpreted according the requestor traffic parameters i.e. a label by itself does not allow knowing the detailed properties of the L2 LSP being requested bi-directional L2 LSPs are indicated by the presence of an upstream label in the Path message.  
. Explicit and Record Routing support     

Ali Sajassi: you mention four different alternatives
alt. 1) using MPLS Label
alt. 2) using MAC as a Label
alt. 3) using VLAN as Label
alt. 4) using new type of label ?

Dimitri: well, it is just defining a new Ethertype as part of the TPID

Ali: what would be the Label in this case ?

Dimitri: the structure as part of the TCI field would be exactly the same (as alt. 3).

Ali: question wrt the primary objective which is end-to-end P2P path using GMPLS control plane. The point which I already made in CCAMP. If you can do it through existing SP switches then why is that not sufficient ?

Dimitri: we are discussing with people involved in IEEE 802.1ad to see how far we can go with that technique and to discuss that more deeply.

Loa: we have just listed here the proposal we had. This is not the purpose of this discussion today to take decision. Just to show there are proposals.

Ali: let me just elaborate on what I meant. The majority of SP switches, not residential/ enterprise, can handle both bridging and MPLS simultaneously and independently

- Cooperation with CCAMP WG (Adrian Farrel)

We have covered relationship with CCAMP well with Alex's comments and those on GELS list. If this work reuses majority of GMPLS with some tweaks then is potentially in-scope for CCAMP. But CCAMP has other work, and this is a nice self-contained unit of work.

CCAMP has been looking for things to spin out (e.g. L1VPN - entirely GMPLS related, but also self-contained). So similarly this work is self-contained, not everyone in CCAMP is interested, but nevertheless want a good, close relationship.

If a WG here wants to change the protocol then want CCAMP to discuss, just as if you changed OSPF you'd want OSPF to discuss.

Dimitri: were you comfortable (as a chair) with what was discussed in GELS BOF preparation document ?

Adrian: speaking as a chair am comfortable with using GMPLS to meet any requirement for which GMPLS is appropriate and don't see that the scenarios here are inappropriate for GMPLS.

Don: this is like the IEEE trying to redefine an IP packet.

Loa: i have to interrupt you, we have said explicitly we were not going to discuss
the definition of the label.

Don: you have serious conflict here. Ethernet is within the charter of IEEE.

Alex Zinin: hold onto that thought. Let us go through the agenda and then will open the mike for discussion.

Zafar Ali: quick question on CCAMP vs this. If there are places where the transit is not Ethernet but just the end-point then there are issues.

Dimitri: we're done with scope. Now will present other proposals. Then open mike.

Loa: we have two proposals here we feel have gained the possibility to get attention they deserve

-----

o) GMPLS Control of Ethernet IVL Switches - 10min
   David Allan
   Document: draft-fedyk-gmpls-ethernet-ivl-00.txt

The aspect of Ethernet that it would be useful to apply a control plane to.
Normally Ethernet switches have two modes of operation (IVL and SVL).
For IVL the switch does a full 60-bit lookup.
So the entire 60 bit value needs to be unique.
Lots of good reasons for not wanting to touch the global uniqueness of MAC addresses, but allowing the VLANs to be only unique when concatenated with MAC.
May require just a few VLANs (possibly as low as one).
If we move away from spanning-tree/flooding to populate tables to using configuration then we've eliminated loop-free constraint.

Peter Busschbach: Clarification question. Are these IVLs performing the 60 bits look-up, Ethernet bridges that can or can't switch an MPLS label ?

Dave Allan: I don't think MPLS enters into that this is purely ...

Peter: no, I'm talking about the bridges, themselves

Dave: Whether or not a bridge implements an MPLS functionality is orthogonal to this discussion.

Peter: we were talking about SP bridges, was mentioned on the first slide. Realistically, are we talking about bridges that do MPLS or do not. I am not concerned whether or not it is defined at IEEE or IETF.

Dave: bridges are not required to do MPLS.

Ali: the best term to use here is bridges. Not switches.

Dave: I'll take responsibility on the terminology.

Ali: one clarification. SVL does 60 bit lookup too, but maps all the VLANs into the same filtering database, whilst IVL maps into separate databases.

Dave: this is simple. If I touch each switch in the path and configure  then I have a path. If have common VLAN ID can have distinct forwarding (per MAC). If have common MAC then can have distinct forwarding (per VLAN). There are lots of wonderful OAM implications of carrying source MAC. Can have O(N) state in core, but still have P2P path. It will work with existing implementations (Nortel's for sure, and can rate limit flooding to zero). As partitioning VLAN space by VLAN ID can run bridging and GMPLS side by side.
Since using Ethernet forwarding as originally defined can use CFM for Ethernet OAM.

Loa: does this mean that wherever you are in the network a frame with a the same combination
of VLAN+MAC will go to the same place.

Dave: depends on the forwarding table configuration. In my example only defined in the path, so outside that path any such frame would be silently discarded.

Kireeti: GMPLS doesn't do MP2P today. However, GLDP would if you had it.

Dave (continuing the presentation): 
. Have priority marking in 802.1p. So queuing separated from forwarding. Very nice property (analogous to E-LSP)
. Could re-purpose just one VLAN ID, but may want multiple VLANs so can have multiple paths to a given destination. Say 16, or 100? Still leaves about 4K VLAN IDs for legacy bridging.
. Control plane aspects - read the draft.
  Signaling bidirectional paths - suggests label upstream etc. 
  Full 108 bit connection ID inferred from info exchange.
. Have spoken to SG15/Q12. Will do for SG13/Q5 and SG15/Q9 shortly.
. Context is Provider Backbone Transport: complementary to 802.1ah (Provider Backbone Bridging), as SP needs to be in control of MACs (so MAC-in-MAC).

Sees this as simple and not a lot of work.

George: say existing IVL switches can do this, but also say that need to tweak data plane.
Inconsistent ?

Dave: for example issue of rate-limiting flooding to zero.

-----

Jaihyung Cho - Label Switched Ethernet (LSE) Architecture (10min)

Use MAC address for label. 
OUI (from IEEE) plus 24 bits of label. 16M is a lot of labels.
Nice to use this as Ethernet switches use MACs. 
Good to have source/dest labels. So bidirectional labels. 
So if there's an issue it is easy to send an error message back to the ingress node. 
Compatible with 802.1Q VLANs.
The difference here to Ethernet switching is that use the shortest path.
No label swapping.

Alex: are you using the original frame header to encode the label are you able to use that area to specify the destination MAC address or not (does this means you loose DA of your frame ?)

Jaihyung: if we assume downstream on demand label allocation then edge nodes may divide  their address space to use in GMPLS domain and then they may for example if a node is determined to use destination address D2 (see slide) they send that information using GMPLS signaling protocols to the ingress node so the ingress node uses that MAC address to find egress for forwarding the frame

Alex: lets discuss later.

Ali: Ethernet switches can't swap MAC_DAs in Ethernet switches. Would need different TCAM etc. Also Alex's question was talking about original (end user) MACs. What happens to the original MAC_DAs ? In this case you're talking IP payloads, right? If your end user has Ethernet header then that comes into the picture.

Jaihyung (continuing the presentation):

Inter-domain case. Need to swap at boundaries.
L2VPN case: use MAC-in-MAC.
Doesn't change Ethernet behavior and is backward compatible with 802.1D/Q.
Doesn't require homogenous deployment...  Good for aggregation/core...

Dimitri: Any clarification question ?

Ali: you said it doesn't change Ethernet behavior - but you require MACs to be changed.

Jaihyung: I agree.

Himanshu Shah: If there are 802.1D bridges between two GMPLS boxes then if you modify
the source/dest MAC then there will be no learning and everything will be broadcast.

Jaihyung: Doesn't change MAC learning, but uses MACs. Please re-read the draft.

-----

o) WG Charter Proposal and Bashing - 5min

Dimitri: 

WG Charter Proposal:

- Work scope: 
  Ethernet networks (aggregation/core agnostic) with a GMPLS control plane 

- Work items:
  . Definition of Ethernet label value space and processing
  . Definition of protocol-independent attributes for describing links and paths that are        required for routing and signaling Ethernet switched point-to-point paths 
  . Specification of routing protocol extensions (OSPF, ISIS) and signalling protocol         extensions (RSVP-TE) required for Ethernet switched point-to-point path establishment 
  . Definition of MIB modules and other OAM techniques  

- Cooperation is foreseen with the following IETF Working Groups (in addition to the CCAMP   WG): OSPF WG, IS-IS WG, MPLS WG and TRILL WG (with TRILL will need to communicate results   of this work.)

- Cooperation is foreseen with IEEE 802.1
  
WG Charter Proposal: Steps and Milestones. 

Step 0: Requirement document - Core group of people to do requirements. 
Step 1: Framework including Terminology and Architecture - We initiated core group to work on framework.  

Both will be used as inputs to decision on Ethernet label format.

Step 2: decision on the Ethernet label(s) format
Step 3: Signaling and Routing Extensions  
Step 4: OAM features and MIB
Step 5: Signaling and Routing Applicability

Peter Busschbach: why limit it to P2P ?

Dimitri: want to walk before running.

Peter: often we find that when we look at other things then the decisions we made earlier
weren't optimal. Why not come up with a solution that works for both ?

Loa: I think your point is understood. Let's take it up later.

Sasha Vainshtein: one option was using the shim header. Do I understand correctly that if we reach that decision then the remaining steps of the charter are unnecessary ?

Loa: almost, yes. In that case then there's very little work, may not make sense to break out in CCAMP, but we're not there yet.

Dimitri: steps 0,1,2 are the major steps to achieve. The remaining ones are mainly dependent on that.

Sasha: to what extent can architecture be decoupled from the decision on the label format ?

Dimitri: the framework identified 2 aspects to be incorporated (terminology and architecture) but they aren't the only ones.

?: have you sent this to IEEE 802. IETF leadership should do this. I also object to item 1 of the charter. What's the right time to do that?

Alex: it is still not clear whether we will end up wanting to change Ethernet formats or not.

Loa: actually you're wrong. We do *not* want to change anything.

Alex: also point at beginning of slides saying work with IEEE as much as possible. Did you contact Bernard ? Did he communicate with IEEE ?

Dimitri: Bernard said open the discussion and he incited to get us invited to the IEEE meetings next week in Vancouver.

Alex: when/if we decide to form a WG, and it appears to be co-operation required with IEEE,
then this will be notified to IEEE through new work announcement and we will engage them.

Zafar: is this something IEEE wants?

Dimitri: the requirements doc is trying to be users saying what they want to achieve with this approach. We want to have the operational requirements on paper in order to help us make the decision. We have asked several people to put together their requirements.

Open discussion
---------------

Alex: after you've made all of your comments, please answer the questions we need to take answers from:
 . whether you believe we have a good understanding of the problem,
 . the direction we are going
 . whether or not we believe there should be WG. 
Will poll the room after that.

Yaakov Stein: I would have been excited about this had it happened a long time ago before we had MPLS standardized and working. There have to be one of two reasons for this (1) retrofit with no changes - seems unlikely or (2) have to have a really good reason (e.g. Dave's suggestion on OAM). Why do we want to do something other than MPLS when we have something that's already  working. I think that's a rhetorical question!

Ali: prime objective is to use GMPLS to set up a P2P path over SP Ethernet switches.

Dimitri: yes

Ali: As I was trying to indicate before, current Service Provider Ethernet switches provide such capability with MPLS shim header and you can have GMPLS. Dave Allen's proposal suggests some to partition VIDs space, some for VLANs bridging and some for GMPLS. Can already do that using one VLAN for MPLS and rest for VLANs. What is the main objective and why do we need to do this differently ?

Don: I object to item one of the charter. That's clearly user plane and in the domain of IEEE. I don't think IETF would like it if IEEE changed MPLS. If you want an Ethertype you need to go to IEEE. I doubt they'll give it to you for a non standard forwarding behavior.
User plane stuff not in scope with this group. Need to talk to the chairman of 802.3 also.

Luca Martini: what you're missing here is the main point of Ethernet. Ethernet is a point to multipoint technology. SP will want to take advantage of that. This doesn't fit at all. It creates a pipe over an infrastructure that isn't a P2P pipe. Doesn't add any functionality above the RFC 3032 shim. Really opposed to WG.

Loa: if we add the P2MP stuff would that be enough ?

Luca: but that wouldn't be GMPLS, would it ? How would you make GMPLS fit that model?

Loa: that's work going on at this moment.

Adrian: P2MP work is GMPLS compliant.

Luca: but it doesn't do broadcast !

Shane Amante: to Ali's point earlier about SP switches doing MPLS. We're currently purchasing hardware that is IP and L2 capable. So having a technique that can forward traffic using L2 only mechanism would be desirable. This work is intriguing and would like to see it move forward.

Ali: I didn't say "all", I said the majority. And I said Ethernet switches. Did you purchase Ethernet switches ?

Shane: yes, it does do bridging, doesn't do MPLS.

Peter: I do support this work. It think it is important. There's a big need for Ethernet without spanning tree and the spanning tree protocol. If we can do that without full MPLS that's a good thing. But needs MP2MP.

Loa: could you clarify P2MP, MP2MP.

Peter: SPs do P2P and MP2MP services so excluding a solution at this point that could not do both is premature.

Dimitri: so you want us to evaluate that as part of this work.

Peter: yes

Dave McDysan: Some Ethernet switches don't do MPLS so I am interested in this work we'd like this to happen. My view is that we're doing something that should possibly have been done sooner but better than never. Also would support looking at topologies other than P2P.

Alex (all hats are off): I remember this all started based on GMPLS. GMPLS was control plane extensions to support transport technologies without changing the data plane. Look at SONET/SDH. What I'm seeing here is a little deviation from that. Original impression about this BoF: controlling Ethernet transport networks with GMPLS CP to allow SPs using some TE there. What I'm seeing here now is divergence into "maybe since we're doing this why not change the data plane?". That's a little too far. We have two viable options:
(1) don't change data plane and stick within the VLAN scope etc. of today.
(2) if we do change it then use MPLS (since we already have that).

Dinesh Mohan: I'd agree with Alex. One question: there's a need to use control plane different to native Ethernet control plane (spanning tree). That is a requirement that is fine. But what I saw in the presentation earlier pre-supposes a solution at the same time.
Saying you need a different control plane doesn't imply that you need label swapping.
Data plane is not within the scope of IETF. If any modification is needed we need to be very careful. The answer is that we shouldn't.

Loa: is there anyone here who said that we wants to change the Ethernet data plane?
Anyone ? We go through this discussion with everyone we talk to. The message is *no changes*.

Alex: the confusion here is when you say "we don't want to" and after we see people who actually do. That's the confusion.

Loa: well then that is a non-starter.

Alex: if we are to start this work then we should abandon all desire to change the data plane and make it very clear to people that present such approaches here.

Dinesh: I would suggest that we have a clear statement that we're not changing the data plane.

Dimitri: this is mentioned as part of the BoF description.

Yakov Rekhter: two points: 1) when talking about changing Ethernet data plane need to consider both syntax and semantics. So, does change in semantics mean a change in the data plane or not? Not clear if it counts?

Alex: yes it counts

Yakov: different people have different opinions.

Alex: it is not enough to say we are not changing the bits on the wire if you change the behavior of how you process MAC addresses or VLAN IDs then that's a change.

Yakov: 2) on discussion of P2MP. I understand the walk before run philosophy. But it depends on how you learn to walk. You may never be able to run. Need to think about P2MP upfront as different choices may have impact on it. May need to think about it up-front. MP2MP may be a service, but can realize it using a collection of P2MP.

Loa: is that the same as saying that in the requirements phase we should consider P2MP as well as P2P, and potentially MP2P ?

Yakov: not potentially, just the first two.

Ali: wrt to data plane, if we want to clarify it would be good to say no changes in data plane functionality both for 802.3 as well 802.1.

Loa: I read from the draft: "Ethernet switches will use the data plane encodings as specified by the IEEE"

Ali: encoding is just bits over the wire this is 802.3. This is different from 802.1.

Dimitri: what you mean is semantics. The BoF description was clearly saying, even if we do
we need to be in agreement (with IEEE) this is the correct way of processing that field.
This is why we need the interaction (with IEEE) to make a check as our interpretation
of how the fields must be processed may be wrong. We need to ask IEEE the exact operation that they have.

Ali: when you refer to IEEE what part of the IEEE are you talking about ? if you tell 802.3 that you're not changing bits on the wire they're happy but 802.1 is a different group. I thought the prime objective to use existing Ethernet switches and put GMPLS control plane. If that's the objective then there should be no changes to 802.1 or 802.3 data plane.

Dimitri: whithin the operations we want to see on these devices it's up to the IEEE to confirm to us whether we are making the right assumptions. It is not up to the IETF to provide such commitment.

Paul (Nortel): if this group is relevant it has to use existing bridges as defined by IEEE.
If we move out of that then the group will be irrelevant. As to P2MP the value prop for Ethernet for carriers is in MP services. So I believe this group should be covering P2P, P2MP and MP.

Loa: Question for Ali. Does this (showing BoF draft text) even remotely satisfy what you
were requesting ? You are invited to rewrite.

?: needs to write as defined by IEEE 802.1 and probably Dimitri proposed charter for this group. It should say that label encoding and forwarding is as per IEEE 802.1.

Dimitri: Thanks, we will address the comment.

Ali: was going to say put 802.3 and 802.1. But 802.1 includes 802.3 so can just put 802.1.

Alex: if we want to disallow changes to the Ethernet data plane then this isn't strong enough as has second sentence. Cut the second sentence.

Zafar: there are certain things that the GMPLS control plane can do. Need a statement that there is a deficiency wrt the control plane today. I'd prefer if IEEE came to us and said "you've got a nice control plane, can we use it, can you extend it for us ?". But that's not the case. I don't know a single deployment of SONET/SDH with a GMPLS control plane. Is this just an academic exercise ?

Loa: Some of us were working on MPLS long before it was even deployed anywhere, so I don't see your point.

Dimitri: This point is orthogonal to the present discussion but I can answer your question. GMPLS *is* deployed for SONET/SDH.

Dee Y: back to conflict with IEEE. Don't think anyone is changing the syntax. As for semantics, IEEE should have a range so that as long as you can get authorization of number space from IEEE or some number assignment organization you can safely do that. All presentations remain under that assumption that as long as they can get the number space they will use it for some purpose or another. That far I do not see any seriously conflict wrt IEEE.

Monique Morrow: what assumptions are we making for OAM behavior ?

Dimitri: initial assumption is 802.1ag. Base is to leave that unaffected.

Dave: I think if I have one concern it is that not all options here are useful. Invariant VLAN gives you 4K connections per network - so useless. VLAN Swapping is per-platform label so connection space of 4K P2P connections per switch. That's inferior to first generation ATM switches.

Ali: we need to make it clear that it is not the case that as long as you leave syntax
unchanged then it's all OK. So wrt the paragraph on changes to the data plane what is the intention of the last sentence ?

Loa: what I want to say is that any changes to the data plane must be done within IEEE.

Ali: So can you please rephrase it ?

Loa: Yes but i want your help to do it.

?: wanted to bring up a separate point. We've been talking about label semantics and forwarding. But what about resource reservation. Work has been done in MEF and ITU about characterizing Ethernet services in terms of information rates, burst sizes etc. That is something this group should also consider.

Richard Rabbat: several people said that a solution (MPLS) already exists. My question to Dimitri/Loa. Why do we need a different solution (to MPLS)? Is it just because you can do it ?

Loa: the point is to set up a P2P connection across an Ethernet network using MAC addresses and VLANS. Can do that today, but can't do TE.

Dee Y.: as long as semantics are about GMPLS, the functional entity inside is not conventional bridge or any other thing, it is a label switch. We're not changing the conventional bridge or MAC boxes, so we're not going into IEEE area in any confliction.

?: the way I understand the charter item is that if you want to suggest MAC swapping then you need to propose it to IEEE.

Dimitri: yes

George Swallow: I've heard people talk about installing hard state using various protocols
(GMPLS is actually a soft-state protocol). I've heard people talking QoS burst sizes,
frame rates, etc. Is this FR/ATM that we'll end-up doing here ?

Mark: this seems like a lot of work because MPLS is not really Ethernet. If we're going to allow changes in IEEE then why not suggest RFC 3032 to 802.1 and be done ?

Jaihyung: the price of Ethernet switches is 1/10 that of router. We don't want to buy routers for core network, but a cheaper device. That's why we're doing this. If we try to implement any technique that requires changes in data plane then we can go to IEEE and propose the data plane changes.

Alex (to the room): points all very clear. Let's try to draw the line. It's very clear that we are not ready at this point to make any decision about forming a working group. It's also clear that IETF is not the right place to change Ethernet data plane. If you need to do that then please go to the appropriate IEEE committees. It seems that several people have expressed interest in TE in the Ethernet transport networks. Either we don't introduce any changes to Ethernet data plane OR we use MPLS.

Would that framework make it worth another BOF ? I see 5 or 6 hands.
And who thinks should not come here again ? 20 people.

Alex (to the room): if you guys want us to consider this one more time (which would be the last time) then you need something different in terms of documents and discussions. This has already been discussed in CCAMP multiple times.

Adrian: whilst there's still discussion on the GELS list about another BOF this is closed on CCAMP.

Meeting is adjourned

-----