Hi Dimitri
The document clearly states:
"The intent of this document is to reuse and align with as much of the
GMPLS protocols as possible. For example reusing the IP control
plane addressing allows the existing signaling, routing, LMP and path
computation to be used as specified. Additions are made only to
accommodate features of Ethernet that are not already supported by
GMPLS. The GMPLS protocols support a set of tools for hierarchical
LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms
support a variety of networks from peer to peer to UNIs and NNIs."
So your question comes down to why we make the statement on L2SC? Like
Lou said when we discussed this we thought that L2SC came with baggage
and was not precise. The switching capabilities would be specified in
documents that address the particular Ethernet data plane. It is true
that if there was a valid Ethernet data plane that could use L2SC
unambiguously it should fit under the architecture. At any rate getting
this right is something that can be accomplished when this is a WG
draft.
Regards,
Don
> -----Original Message-----
> From: PAPADIMITRIOU Dimitri
> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]
> Sent: Wednesday, January 23, 2008 7:05 PM
> To: Lou Berger
> Cc: Fedyk, Don (BL60:1A00); BRUNGARD, DEBORAH A, ATTLABS;
> ccamp@ops.ietf.org
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>
> the question triggered by this poll is the following: if GMPLS for
> Ethernet is not inline with the existing stacks what is the value of
> GMPLS re-use ? what's the value to borrow the term GMPLS without its
> substance ? and in practice, the issue is, if it is not GMPLS per RFC
> 3945, what's the value compared to any other native control stack that
> would be developed at IEEE for inst. for these techno's.
>
> you quote:
>
> > L2SC was always underspecified (e.g., covers both ATM and Ether),
>
> additional specification does not result in departing from the initial
> definition but refinement of the initial definition (definition of a
> sub-set not a side definition).
>
> probably the document is not mature enough to respond to the
> tie-breaker: what about the FIT of GMPLS for Ethernet but not
> within the
> L2SC space (as defined today) ? but in the meantime preclude
> any allowed
> use of GMPLS per IETF RFCs to Ethernet if they do not comply
> with a new
> WG i-d would create a precedent in the history of this WG with really
> disastrous impact (including on other application of GMPLS)
>
> we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to
> assess consequences before going one way or another and under which
> conditions.
>
> -d.
>
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger
> > Sent: Wednesday, January 23, 2008 1:09 AM
> > To: PAPADIMITRIOU Dimitri
> > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > ccamp@ops.ietf.org
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >
> > We've always had different switching type/capability in
> > GMPLS. Nothing new here.
> >
> > L2SC was always underspecified (e.g., covers both ATM and
> Ether), is
> > currently used by some for different purposes, and doesn't allow
> > unique identification of switching capabilities of an interface. I
> > *really* don't see the unique identification of an interface's
> > Ethernet switching function as any different from what is done for
> > today for the other types or as any big deal or change in GMPLS
> > direction or architecture.
> >
> > but, that's just my perspective.
> >
> > Lou
> >
> > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> > >thus the question is whether or not to ask for a change
> CCAMP "common
> > >control" in DCAMP "differentiated control" per technology ?
> > >
> > >we never have had a techno inducing a base building block
> > change (GMPLS
> > >being a generalisation of MPLS-TE). i'm afraid that
> generalized LSP,
> > >generalized LSR, generalized label, etc. per GMPLS arch (RFC
> > 3945) would
> > >simply be unapplicable as known today and thus the corr.
> > base protocol
> > >specs unapplicable. at the end the term "GMPLS" would be
> > emptied of any
> > >real substance.
> > >
> > >it's a choice but let's ask the questions from the right
> perspective.
> > >
> > >-d.
> > >
> > > > -----Original Message-----
> > > > From: Lou Berger [mailto:lberger@labn.net]
> > > > Sent: Tuesday, January 22, 2008 11:28 PM
> > > > To: PAPADIMITRIOU Dimitri
> > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > > > ccamp@ops.ietf.org
> > > > Subject: RE: Proposed WG Draft -
> draft-gmpls-ethernet-arch-00.txt
> > > >
> > > > I have no objection to adding "Updates: 3945" to the
> > document header
> > > > and matching 3945's category.
> > > >
> > > > Lou
> > > >
> > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> > > > >Lou
> > > > >
> > > > >what i am concerned with: is that the doc extends
> > > > applicability of GMPLS
> > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945
> > ? does that
> > > > >make sense ?
> > > > >
> > > > >what's needed instead of hiding behind terms is to state
> > GMPLS for Y,
> > > > >where Y includes the set of Ethernet-based techno's under
> > > > development at
> > > > >places as indicated in the doc itself. instead of
> > inducing by a title
> > > > >such as "GMPLS for Ethernet" that this doc supersedes any
> > > > previous work
> > > > >in that
> > > > >space.
> > > > >
> > > > >-d.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: owner-ccamp@ops.ietf.org
> > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger
> > > > > > Sent: Tuesday, January 22, 2008 10:50 PM
> > > > > > To: Don Fedyk
> > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;
> > > > > > ccamp@ops.ietf.org
> > > > > > Subject: RE: Proposed WG Draft -
> > draft-gmpls-ethernet-arch-00.txt
> > > > > >
> > > > > > Don,
> > > > > > I agree 100%. Furthermore there is no
> > statement in the
> > > > > > draft that 3945 doesn't apply, in fact it explicitly
> > says just the
> > > > > > opposite. The reason for the statement in question is
> > > > simply as you
> > > > > > say, and to ensure full ETH-LSP definition and interoperable
> > > > > > operation a new switching type/capability is required.
> > > > > >
> > > > > > It's really not such a bid deal or major change.
> > > > > >
> > > > > > Lou
> > > > > >
> > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote:
> > > > > > >Hi Dimitri
> > > > > > >
> > > > > > >The text you quote was put in the architecture/
> > framework, not to
> > > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining
> > > > > > L2SC, which
> > > > > > >has been there for many years and may be in use.
> > > > > > >
> > > > > > >Perhaps the working needs to be adjusted but I don't think
> > > > > > it is a major
> > > > > > >issue.
> > > > > > >
> > > > > > >Regards,
> > > > > > >Don
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: owner-ccamp@ops.ietf.org
> > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of
> > > > > > PAPADIMITRIOU Dimitri
> > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM
> > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org
> > > > > > > > Subject: RE: Proposed WG Draft -
> > > > draft-gmpls-ethernet-arch-00.txt
> > > > > > > >
> > > > > > > > All,
> > > > > > > >
> > > > > > > > > We received a couple of comments in the
> > meeting, we would
> > > > > > > > > appreciate additional feedback on the list.
> > > > > > > >
> > > > > > > > The document states:
> > > > > > > >
> > > > > > > > "The L2SC Interface Switching Capabilities MUST
> > NOT be used
> > > > > > > > to represent
> > > > > > > > interfaces capable of supporting Eth-LSPs.
> > Interface Switching
> > > > > > > > Capability specific TE information may be defined as
> > > > > > needed to support
> > > > > > > > the requirements of a specific Ethernet Switching
> > > > Service Type."
> > > > > > > >
> > > > > > > > [...]
> > > > > > > >
> > > > > > > > "It is expected that there will be no case where an
> > > > > > Eth-LSP will be
> > > > > > > > signaled, or an Eth-LSP supporting interface will be
> > > > > > > > represented, using
> > > > > > > > the L2SC switching type/capability. A new switching
> > > > > > type/capability is
> > > > > > > > required to avoid any potential current usage
> of the L2SC
> > > > > > switching
> > > > > > > > type/capability in support of Ethernet."
> > > > > > > >
> > > > > > > > This is explicit statement that GMPLS per RFC
> 3945 is not
> > > > > > applicable.
> > > > > > > > So, it is much more than just an additional
> codepoint, as
> > > > > > the control
> > > > > > > > plane behaviour is to be defined for this
> > codepoint. So, it
> > > > > > > > is the open
> > > > > > > > door for a new control plane behaviour.
> > > > > > > >
> > > > > > > > so, let's have a more basic questioning before jumping
> > > > > > into the single
> > > > > > > > alternative resulting from this doc.:
> > > > > > > >
> > > > > > > > - either it is GMPLS for Ethernet architecture and then
> > > > > > what exist in
> > > > > > > > current RFCs should be applicable (because i do not see
> > > > > > any rationale
> > > > > > > > for L2SC def. departure for Ethernet frame processing);
> > > > > > > >
> > > > > > > > - or not it is X for Y architecture, where X is an IP
> > > > > > control protocol
> > > > > > > > based some potentially on some existing GMPLS blocks
> > > > and Y is not
> > > > > > > > compatible with the existing definition of Eth frame
> > > > processing.
> > > > > > > >
> > > > > > > > In the latter case, i do not know how this WG can deal
> > > > > > with such case
> > > > > > > > (from the control plane perspective).
> > > > > > > >
> > > > > > > > -d.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: owner-ccamp@ops.ietf.org
> > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf
> Of BRUNGARD,
> > > > > > > > > DEBORAH A, ATTLABS
> > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > > > > > > > To: ccamp@ops.ietf.org
> > > > > > > > > Subject: Proposed WG Draft -
> > > > draft-gmpls-ethernet-arch-00.txt
> > > > > > > > >
> > > > > > > > > CCAMP,
> > > > > > > > >
> > > > > > > > > The DT proposed in their meeting presentation
> for their
> > > > > > > > > architecture and framework document to be
> accepted as a
> > > > > > WG draft:
> > > > > > > > >
> > > > > >
> > > >
> > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > > > > > > > >
> > > > > > > > > We received a couple of comments in the
> > meeting, we would
> > > > > > > > > appreciate additional feedback on the list.
> > Please express
> > > > > > > > > your support (or otherwise) for this I-D to become
> > > > a WG draft.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Deborah
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
> >
>