| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Here are my comments to your earlier note after some in depth investigation.
I agree that the "layering approach to" Connectivity Management
is a very relevant topic for 802.1. Where I don't agree with
your comments in the note is your alluding to "service providers who are
principally interested in this work" as a reason to have the SEC
approve a PAR for 802.1. Since I am the liaison from 802.3 to 802.1,
I have closely monitored the Ethernet transport focused connectivity fault
management position that has been presented in the 802.1 meetings.
In all of these, I have seen little interest expressed by true service
providers. While NTT, SBC, FT and MCI have attended some of these
meetings, only NTT has made a presentation and their (NTT) presentation
in November was more a plea to consider OAM from the ITU-T perspective
which is where these service providers are very active. What is worrisome
for me as a long time supporter of and participant in 802 standards and
should also be a concern for the SEC, is that the lead participant from
one of the major service provider/carriers has stopped participating because
he feels that his input was not being heard on the 802.1 reflector.
This has only stifled the debate for him. France Telecom and SBC
have been attending but my input says that they are only attempting to
determine where this idea is going. Schedule a Call For Interest,
and I guarantee that one of their representatives will speak out, and maybe
even provide some detailed guidance on the service issues that the project
should should consider for carriers.
So 802.1 might claim that we have the right to define fault management for carriers. My company is one of those vendors who probably feel in some sector that we know how to do this and must push forward with our vendor perspective. But I am not a participant in IEEE 802 as a corporate representative of Nortel Networks. I am lucky and I am thankful that so far Nortel allows Geoff and myself (others too) to take positions of our own belief as individuals. The good news for me is that I have it both ways and my corporate position also allows me to approach most if not all of the service providers that you define in your note as: "service providers who are principally interested in this work" for their opinion. I strongly believe that their interest must be aired in a CFI for all of us vendors to hear.
Based on my research, we in 802.1 do not have the service providers "terms" yet defined. Therefore, I propose that this concept of Fault Management needs much socialization within 802 as well as ITU-T. Given the clear directive of Paul N. last summer in the 802.3 Interim in Italy, I have become much more active in bringing 802 and ITU-T SG15 together.
Paul and those of you on the SEC, a CFI on this topic would be the ideal place to begin this collective standards work now that 802 is venturing into the WAN . FYI, our next meeting of ITU SG 15 occurs the month following our March 802 plenary and I will be the first to stand up there in that plenary and ask the many service providers in attendance to come to our July 802 meeting to express their various positions relative to a CFI on carrier fault management. This is new ground for our group and needs serious scrutiny.
Therefore, based on my recent experience with the carriers, we in 802 need to require a general CFI on this topic before a PAR is granted. Remember, those of you on the SEC who are wireless vendors must understand that network fault management is a key issue for your technology initiatives too.
Sincerely,
Richard Brand
Liaison to 802.1 from 802.3
Mick Seaman wrote:
Richard,One of the items that has been intensively discussed in the 802.1 meetings
is the layering approach to connectivity management (amongst other aspectslly inter
of "OAM") used by "the service providers who are principally interested in
this work"
I can't mimic their terms, but essentially the approach is to isolate faults
to the limits of one's visibility at a certain layer in the hierarchy, and
then from one or more of the boundary points at that layer of visibility to
ask questions of the layer below (or make a request to someone who is able
and authorized to do so). For example users may see and end to end service,
with little detail about how that service is made up of separate providers,
each of which does not (by policy) reveal the internal details of how they
carry traffic.This model applies right layer by layer or step by step from the grand
detail to the eventual micro-detail. Just as it applies to connections
fulfilled by a number of concatenated providers, each providing connections
using many LANs concatenated by bridges, the same layering of concerns
applies to the difference between LANs concatenated by bridges as opposed to
the internal details of the LANs themselves (stations interconnected by
media access control specific methods).This model is important as it means that 802.1 is not trying to boil the
ocean with this PAR, and in particular it is not trying to boil the seas and
rivers that compose each of the individual MACs. There is absolutely no
suggestion anywhere that MAC specific detail should feature in this work.
Given the complexity of new MACs I am not at all surprised that fault
management for an individual MAC proves far more difficult than fault
management at the level of bridges operating using those MACs (or at the
level subnetworks of bridges that use those MACs).Mick
-----Original Message-----
From: owner-stds-802-1@majordomo.ieee.org
[mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Richard Brand
Sent: Tuesday, January 27, 2004 1:58 PM
To: Tony Jeffree
Cc: stds-802-sec@ieee.org; stds-802-1@ieee.org; Grow, Bob;
dpannell@marvel.com
Subject: Re: [802.1] Connectivity Fault Management draft PARTony:
Having read the draft, seeing a portion of the very large slide presentation
made
at the January interim, and then rereading the scope of this PAR covering
"transport fault management", I would offer that this is major new work
effort
for 802.1 that could have a major effect on many if not all 802 members.
Fault
management has potential applicability to all 802 LANs.
Given this scope, I would strongly recommend that an 802.1 Study Group be
formed
for this activity before the requesting of a PAR, in order to give notice
for all
802 members of your intentions. However, in line with the contents of
Procedure
2, I would settle for an evening tutorial presentation in March as is
"highly
recommended" in the Procedure. This would allow all 802 members the
opportunity
to participate/provide input for a potential PAR in July.
In this case, I am speaking for myself as a member and not for the 802.3
Working
Group, however I will bring it up to my group at our March plenary. FYI,
802.3
ran thru many study group meetings in arriving at an acceptable scope for
our OAM
segment of P802.3ah and we only had one MAC to deal with.
Regards,
Richard Brand
Liaison rep from 802.3 to 802.1Tony Jeffree wrote:
> This is notification under Procedure 2 - "Procedure for PARs" that 802.1
> intends to request SEC approval of the following draft PAR at the March
> 2004 closing SEC meeting:
>
>
http://www.ieee802.org/1/files/public/docs2004/ConnectivityFaultPAR-v1.2a.do
c
>
> Regards,
> Tony
>
> =>IEEE 802.1 Email List user information:
> http://www.ieee802.org/1/email-pages/
begin:vcard n:Brand;Richard C. tel;work:(408) 495 2462 : ESN 265 2462 x-mozilla-html:FALSE org:Advanced Technology adr:;;4655 Great America Pkway;Santa Clara;Ca.;95054; version:2.1 email;internet:rbrand@Nortelnetworks.com title:Director, Network Architecture & Applications fn:Richard C. Brand end:vcard