Re: Proposed CCAMP recharter

[dimitri papadimitriou <dpapadimitriou@psg.com>]

don & adrian

> 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".

i think the concern is to draw a line between VLAN-bridged Ethernet/MSTP 
and X/Y, where Y is what is under discussion at CCAMP and X is what one 
tries with this thread to qualify e.g. "source-controlled and 
explicitly-routed Ethernet data paths" (approved by an SDO responsible 
for the Ethernet data plane) or something along these lines would 
prevent that confusion.

-d.

Don Fedyk 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 
>
>
>
>
>
> .