[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed CCAMP recharter
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin
> Sent: Thursday, August 16, 2007 4:21 PM
> To: Don Fedyk; Adrian Farrel; MEURIC Julien RD-CORE-LAN
> Cc: ccamp@ops.ietf.org
> Subject: RE: Proposed CCAMP recharter
>
> Adrian is proposing:
>
> - Work on GMPLS procedures and extensions to support
> source-controlled and explicitly-routed Ethernet data paths
> for Ethernet data planes that are already approved by an SDO
> with responsibility for the Ethernet data plane....
>
> IMO this is lacking the fact that while computing the
> mentioned paths we will consider various TE proprieties of
> Ethernet links, and while setting up the paths we will
> perform resource reservation. I mean explicitly routed paths
> may be computed and established without any TE
> considerations, and that's not what we are planning to do in CCAMP.
>
> So, I would change the text to something like:
>
> - Work on GMPLS procedures and extensions to support Traffic
> Engineered Ethernet data paths for Ethernet data planes that
> are already approved by an SDO with responsibility for the
> Ethernet data plane....
if you do so, you then come back to the initial issue. TE data
paths & mechanisms are not CCAMP specific (and may applied to
bridged Ethernet) hence you would not characterize the Ethernet
mode - see my previous post -
so suggest to rephrase as:
- Work on traffic-engineering mechanisms and extensions to
support source-controlled and explicitly-routed Ethernet
data paths for Ethernet data planes that are already approved
by an SDO with responsibility for the Ethernet data plane. It
is expected that the primary SDO in this case is the IEEE.
Note that the specification or modification of Ethernet data
planes is out of scope.
-d.
> Don Fedyk <dwfedyk@nortel.com> wrote:
>
> Hi Adrian
>
> It's OK you disagree. :-) I myself would have used the
> term connection oriented a while back. However I have
> observed that others have a different interpretation and
> connection oriented Ethernet is confusing to that crowd. I do
> believe this a difference between service and network as you
> point out but traditional Ethernet has a tighter coupling
> between network and service and the distinction is more
> subtle. Ethernet packets are not forwarded in a hop by hop
> paradigm, they follow a VLAN or source based tree always.
>
> So rather than put confusing text I prefer what Adrian
> has proposed.
>
> Regards,
> Don
>
>
> ________________________________
>
> From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
> Sent: Thursday, August 16, 2007 9:32 AM
> To: Fedyk, Don (BL60:1A00); Adrian Farrel;
> MEURIC Julien RD-CORE-LAN
> Cc: ccamp@ops.ietf.org
> Subject: RE: Proposed CCAMP recharter
>
>
> Hi Don,
>
> I disagree with you on this.
>
> It all depends on definition of connection. If
> one agrees on the following major properties of a p2p/p2mp connection:
>
> a) single source;
> b) zero flexibility in forwarding packets along
> the connection;
> c) deterministic resource reservation
>
> then one can see the difference between, say,
> Ethernet service (which is an association between source(s)
> and destination(s)) and Ethernet connection (which is a set
> of network resources connecting the source to the
> destination(s)). Ethernet services may be provided by either
> connection-oriented or connectionless Ethernet networks.
> Ethernet services, as we know, may be also provided by
> non-Ethernet (e.g. IP/MPLS) networks).
> PBB-TE IMO is all about Ethernet connections
> rather than Ethernet services.
>
> The bottom line: I think it is correct to have
> the "connection-oriented Ethernet" clause in the CCAMP charter.
>
> Igor
>
> Don Fedyk <dwfedyk@nortel.com> wrote:
>
> Hi Adrian
>
> Hi Adrian
>
> The description of the term
> "connection-oriented" does not hold quite
> the same meaning in the IEEE as in the
> IETF. In IEEE, my understanding
> is that unicast and multicast services
> in Ethernet are all considered
> "connections" or "associations" when
> they are part of the same Service
> VLAN or Service Instance. So many types
> of Ethernet services can be
> considered "connection-oriented".
>
> Therefore the term
> "connection-oriented" might be confusing. (The IETF
> also considers TCP "connection
> oriented" even though IP is
> connectionless datagram based.)
>
> I would suggest we use something
> descriptive like "Explicit Route
> Controlled Paths", or "Automating
> Configured Ethernet Paths".
>
> Just a suggestion,
> Don
>
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On
> Behalf Of Adrian Farrel
> Hi Julien,
>
> > I agree with Dimitri about the use of
> the term "Ethernet". As we don't
> > control IP but MPLS-TE, we're looking
> into controlling a "connection-
> > oriented Ethernet" which isn't really
> Ethernet and not supported by
> > typical "Ethernet switches".
>
> OK. I'll modify the text I just
> suggested to Dimitri, to say
> "connection-oriented"
>
> > On the other hand, (echoing Dimitri again)
> > we are also considering Ethernet
> services over any GMPLS-controlled
> > layer.
>
> Agree. But don't think we need milestones.
>
> > I also agree it is useless to
> rearrange all short-term milestones
> (unlike
> > the
> > charter which has a more long-term value).
>
> I tend to agree, but I suspect that the
> IESG will find it hard to
> approve a
> re-charter with dates that have been passed.
>
> Thanks,
> Adrian
>
>
>
>
>
>
>
> ________________________________
>
> Pinpoint customers
> <http://us.rd.yahoo.com/evt=48250/*http://searchmarketing.yaho
> o.com/arp/sponsoredsearch_v9.php?o=US2226&cmp=Yahoo&ctv=AprNI&
> s=Y&s2=EM&b=50> who are looking for what you sell.
>
>
> ________________________________
>
> Yahoo! oneSearch: Finally, mobile search that gives answers
> <http://us.rd.yahoo.com/evt=48252/*http://mobile.yahoo.com/mob
> ileweb/onesearch?refer=1ONXIC> , not web links.
>