Re: [EFM] Re: openaccess issues ...
>
>
> 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
>
>