[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

To: "Don Fedyk" <dwfedyk@nortel.com>, "Lou Berger" <lberger@labn.net>
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>
Date: Thu, 24 Jan 2008 09:23:21 +0100
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>, <ccamp@ops.ietf.org>
In-reply-to: <34B3EAA5B3066A42914D28C5ECF5FEA41349EF98@zrtphxm2.corp.nortel.com>
References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <D91369E6E2EF0A4E9E39997A196E4755233B7D@FRVELSMBS22.ad2.ad.alcatel.com> <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> <E1JHR0g-0005g6-7R@psg.com> <D91369E6E2EF0A4E9E39997A196E4755233B87@FRVELSMBS22.ad2.ad.alcatel.com> <200801222228.m0MMRxVa004316@mailgate4.alcatel.fr> <D91369E6E2EF0A4E9E39997A196E4755233B8D@FRVELSMBS22.ad2.ad.alcatel.com> <E1JHTAr-000JFX-Gk@psg.com> <D91369E6E2EF0A4E9E39997A196E4755233FC1@FRVELSMBS22.ad2.ad.alcatel.com> <34B3EAA5B3066A42914D28C5ECF5FEA41349EF98@zrtphxm2.corp.nortel.com>

Hi Don

so, what's wrong with the definition of L2SC then ? from 3945:

   2. Layer-2 Switch Capable (L2SC) interfaces:

      Interfaces that recognize frame/cell boundaries and can switch
      data based on the content of the frame/cell header.  Examples
      include interfaces on Ethernet bridges that switch data based on
      the content of the MAC header and interfaces on ATM-LSRs that
      forward data based on the ATM VPI/VCI. 

as such the statement "A new switching type/capability is required to
avoid any potential current usage of the L2SC switching type/capability 
in support of Ethernet." is made but never explained why in the doc -

now coming down to the first sentence you indicated from your doc.

"The intent of this document is to reuse and align with as much of the
GMPLS protocols as possible.... Additions are made only to accommodate 
features of Ethernet that are not already supported by GMPLS."

It should have been something like: "This doc. details the GMPLS
protocol suite architecture for Ethernet. Extensions are made only 
to accommodate features of Ethernet that are not already supported 
by GMPLS RFCs and inline with its architecture defined in RFC 3945."

otherwise the result would be progressively that all GMPLS RFCs are
cracked down to accommodate Ethernet.

thanks,
-d.

> -----Original Message-----
> From: Don Fedyk [mailto:dwfedyk@nortel.com] 
> Sent: Thursday, January 24, 2008 3:51 AM
> To: PAPADIMITRIOU Dimitri; Lou Berger
> Cc: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> 
> 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
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > 
> > > 
> > > 
> > 
>

References:
- Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
  - From: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>
- RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
  - From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>
- RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
  - From: "Don Fedyk" <dwfedyk@nortel.com>
- RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
  - From: Lou Berger <lberger@labn.net>
- RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
  - From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>
- RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
  - From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>
- RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
  - From: Lou Berger <lberger@labn.net>
- RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
  - From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>
- RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
  - From: "Don Fedyk" <dwfedyk@nortel.com>

Prev by Date: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Next by Date: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Previous by thread: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Next by thread: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Index(es):
- Date
- Thread