Hi Dimitri
> dave - there was a lengthy off-line discussion suggested by
> the chairs
> intended to explain you the scope of the draft and its
> relatioship with
> the ethernet data plane (after the question you raised during the f2f
> meeting) - this has been done and we have explained (via a lengthy
> exchange of e-mails) that this document and so the use of gmpls to
> control ethernet frame flows, is not targeting control of bridged
> ethernet environments
Yes, I have archived that discussion, consumes a reaonsable amount of my disk space ;-)
- if this is not clear from the current
> document
> introduction we would have also to work on this part of the
> document -
Yes I do beleive the document needs work to clarify many of the sources of confusion we discussed, my suggestion is an applicability statement
> therefore, the below reference to MSTP is not in the current
> scope;
I think the question is what has utility relative to existing standards, ability to define an ethernet FEC as either a port (Single spanning tree topology) or MSTP instance (multiple spanning trees) so that the GMPLS signalled topology can be resolved to somthing Ethernet understands has utility.
> on
> the other side, the use of the term "VLAN label" has created some
> confusion; therefore, in a next release i will simply refer
> to a "label"
> of 32 bits (unstructured) because the intention was (and still is) to
> find an easy way to map the control of the ethernet frame
> flows on each
> device they traverses without making any assumption on how
> this flow is
> processed inside each node at the data plane level (note: on label
> values, RFC 3946 took an equivalent approach - for circuits - where
> sonet/sdh multiplexing structures have been used to create unique
> multiplex entry names i.e. labels - this concept is here applied for
> "virtual" circuits), so, if the working group is willing to
> enter into a
> data plane oriented discussion to clarify the behaviour(s) onto which
> the present approach would be potentially applicable this is
> fine with
> me as long as we are within the scope of the initial motivations
Yes, if we are discussing labels and not FECs and a label is required to discriminate the exsiting flow IMO it should be an MPLS label. This puts us back towards Deborah's analogy that this is PW signalling (a la dry martini...my interpretation), if so haven't we already specified the control plane in another WG?
Dave