RE: [EFM] Re: openaccess issues ...
All
I agree, outside of EFM is probably a better place at this stage. Three out
of the four EFM tracks have major issues with consensus. Introducing a
disruptive technology proposal into the one track with consenus is unlikely
to engender support.
Best regards
Bob
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Bruce
Tolley
Sent: 22 February 2002 17:44
To: Hugh Barrass; f.menard@xxxxxxxxxxxxxxx
Cc: owner-stds-802-3-efm-p2mp@majordomo.ieee.org;
stds-802-3-efm@ieee.org; owner-stds-802-3-efm-p2p@majordomo.ieee.org
Subject: Re: [EFM] Re: openaccess issues ...
Hugh
Yes the topics are somewhat orthogonal to the IEEE 802.3ah goals.
That being said, the topics are important.
Maybe we can form an ad hoc in St Louis and plan a tutorial for the next
meeting outside the 802.3ah agenda. Many of the Ethernet experts are not
aware of lthe egal and regulatory issues impact the customer space we are
trying to build EFM technologies for.
Bruce
At 09:00 AM 2/22/2002 -0800, Hugh Barrass wrote:
>Francois and others,
>
>I strongly suggest that this discussion should not take place on the
802.3ah
>reflector. This type of discussion may be appropriate to the EFM Alliance
>(would
>one of the EFM people like to take it up?) or in private e-mail.
>
>Hugh.
>
>"Francois D. Menard" wrote:
>
> > > I am trying to sting together some interesting topics for the
> > > March meeting to deal with unbundling fiber, open access for
> > > services (with a revenue stream that works for the owner of
> > > the infrastructure/transport/facility,
> > > call it what you will, straight billing and revenue share),
> > > and a technical proposal that can demonstrate both technical
> > > suitability (hence broad market acceptance), and a
> > > comparatively low cost of implementation. We will also try to
> > > address the OAM transport wars and the subject of QoS. Other
> > > than that we will have very little to say :-). I think the
> > > March meeting will be one of the most critical in the history
> > > of EFM. Hope you can be there.
> >
> > Bob, others,
> >
> > I've been researching these issues for quite a bit of time already. We
> > have open access on ADSL and Cable Modem in Canada that is quite
> > advanced in the regulatory circles. I would encourage that we hold a
> > CC: based discussion on that. My personal view is that the closest that
> > FTTH stays to opening the actual support structures for fiber, the
> > better. Then, issues grow more complicated the higher up in the
> > protocol stack. Opening up the OSP, then opening up VLANs, then opening
> > up at the IP routing layer, etc. It is my hope that groups such as the
> > FTTH Council will begin to focus on these issues.
> >
> > With regards to EFM, I know that we will come under fire very quickly if
> > we don't stick to issues with defining open access requirements that do
> > fall within the system's view of EFM. We will quickly be told that
> > those are not PDM issues and that therefore they should be discussed
> > elsewhere. However, we do have systems problem that are not being
> > addressed elsewhere, and would believe that the standard would benefit
> > from involvement of EFM participants.
> >
> > For example, I believe that we have significant issues associated with
> > managing VLANs (i.e. how do you make an IP Phone on CPE port 1 go to SP1
> > and a PC on CPE port 2 go to SP2, etc). As a result of a very
> > interesting meeting that I held yesterday with specialists in IPv6, I am
> > now suspicious that we will have another significant issue with the
> > practical payload size available to the application layer inside an EFM
> > packet, once all of the desired features are actually put to use in an
> > EFM system.
> >
> > Bottom line: open access considerations in EFM could open up issues
> > related to physical layer systems issues, data-link layer systems issues
> > & network-layer systems issues. Even access by other SP's to actual OAM
> > frames is important. OAM in frames would be so much better from the
> > perspective that it could traverse the complete EFM system, from the
> > actual IP phone to the service provider (this brings up the issue of LLC
> > for OAM once again). Why shouldn't service providers be allowed to
> > monitor for link failures across home LANs?
> >
> > A quick overview of the actual IPv6 stack will show that once IP
> > tunneling is in place, IPSec is used & routing extension headers are
> > used for constraint-based routing by Source Address, the actual
> > remaining payload size for IP applications inside an Ethernet frame will
> > be of a few hundred bytes instead of the 1300+ Kbytes that we're all
> > used to. At the risk of being reprimanded for bringing up the issue of
> > jumbo frames, I would share my belief that for us to duck away from
> > dealing with these issues (from a system's view of EFM) would not do any
> > good to the long-term market potential of the standard either. Just to
> > remind people, whereas IPv4 can support packet sizes of up to 65 Kbytes,
> > IPv6 can support packets up to 4 Gbytes, a far cry from what's possible
> > with Ethernet today.
> >
> > We must not avoid dealing with these issues in EFM, however, we would
> > certainly aim to prioritize and focus.
> >
> > -=Francois=-
> > f.menard@xxxxxxxxxxxxxxx
> > 819 692 1383