[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
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
> > > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>