[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
>
>
>