Neil/Tom:
Somthing that is missing from this discussion is an appreciation of the applicability of, limitations of..and deployment scenarios for Y.1711. It is not a panacea, nor is it a product of some networking "axis of evil".
Y.1711 simply provides some defect detection/handling tools that can be implemented on LERs for explicitly routed p2p LSPs regardless of payload, and defines a framework and criteria for doing availability measurement with the same tools. When used in this fashion, it can be overlaid on an existing network and would work just fine as there are no dependencies on the intermediate LSRs. There are no backward compatibility issues, and the mechanism itself is quite lightweight, suggesting simple H/W assisted implementation on the edge devices. It's not hard to imagine all the places it could be used, as well as the places where it would add no value.
As such I'm not sure why folks are labelling this as a non-starter, similarly I'm also seeing preliminary marketing literature suggesting that by the mere existence of OAM as a topic means the problems have been solved. IMHO neither is true.
What I got out of the BOF last December (and subsequent e-mail blizzard) is that there are some operators and some vendors who don't think an MPLS specific approach is useful and a similar camp who do (and we're all quite passionate about it).
Seems to me that if you examine the facts, there is room for both camps to co-exist.
cheers
Dave
> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Sunday, March 03, 2002 6:24 PM
> To: tnadeau@cisco.com
> Cc: ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02
>
>
> Tom,
>
> You keep making assertions like like 'grand architecture' and
> stating a need
> for 'simpler solutions' but you offer no quantification of
> such, and seem
> quite happy to shift the defect detection/handling
> problems/costs towards
> the operator.
>
> To break the deadlock, let me ask you to answer a simple question:
>
> - The CV pkt is a simple 'keepalive' in the data-plane
> carrying the
> LSP source address......many protocols use such a device,
> this one just
> happens to look after the customer traffic (you know, the
> stuff that earns
> carrier's money?). This is about it complexity-wise as regards defect
> detection. The only other things defined are an FDI pkt
> (forward) and BDI
> pkt (backward) notifications which only appear after a defect
> is detected.
> I think we would all therefore benefit if you can please
> quantify why this
> single CV pkt is so complex as you keep asserting....esp given all the
> 'grand arch' benefits it brings? We await your comparative technical
> analysis and costings for review.
>
> regards, Neil
>
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > Sent: 03 March 2002 18:30
> > To: neil.2.harrison
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> >
> > Neil,
> >
> > I am very glad that you have taken the time to reply to my
> > response. Regards Tom.
> >
> > >Hi Tom...I am very glad you raised these points....please see my
> > >observations on them. regards Neil
> > >
> > ><snip>
> > > > Achitectural correctness is bunk if it
> > > > does not leads to
> > > > implementations that cannot support the architecture in such
> > > > a way as to a) be
> > > > implemented in one's lifetime,
> > >NH=> I wholeheartedly agree with this......and for as long
> > as I can remember
> > >management-plane X-I/Fs have been promised but never materialised.
> >
> > Again you misstate the facts. Management IFs exist
> > today: SNMP,
> > LSP ping, etc...
> >
> > >However,
> > >wrt to the topic here I am already aware of trial
> > implementations by certain
> > >vendors and Shahram Davari has been involved since very
> early on....
> > >and since his company cuts the silicon many then use then
> > this tells me it
> > >can't
> > >be be too complex. Maybe this is just a problem for your
> > company?....a
> > >quick look-see at who has problems seems to indicate Cisco
> > figures largely
> > >here in a class of 1.
> >
> > Lets not misrepresent the facts again. There are
> > lots of equipment
> > vendors
> > who think that there are alternative ways of achieving defect
> > detection/repair using
> > simpler, more practical mechanisms. These same vendors and
> > operators alike
> > spoke out at the OAM BOF against your grand architecture of
> > OAM for this
> > reason. I have also been told this numerous times by
> > operational carrier
> > types privately as well.
> >
> > > > Please don't just refer us again to your OAM draft,
> > > > because I think it is clear that is a non-starter.
> > >NH=> Why is this.....and are you speaking on behalf of
> > yourself, Cisco or
> > >the IETF?
> >
> > People at the IETF speak for themselves. Read the
> > IETF guidelines
> > if you are unclear on this.
> >
> > >By saying this you are also stating that you also don't
> > >value/respect the fact that these requirements are supported by the
> > >following carriers AT&T, SBC, NTT, DT, Sprint, BT (+ a list of
> > >manafuacturers, who are prepared it seems to meet these
> > requirements).
> > >You offer no rationale for this statement.......so I can
> > only assume you (or
> > >your company) disagree with these carrier's requirements.
> >
> > I always value the input of carriers, and
> specifically weigh
> > heavily the input
> > from their operational organizations (versus marketing or
> > research). I
> > learned this
> > lesson a long time ago. It is what drives what I do every
> day. Crrier
> > representatives
> > who are on the operational side of their organizations have
> > expressed concern
> > publicly and to me privately over these requirements and the
> > approaches
> > proposed
> > to solve them in Y.1711. I am hearing that people want to
> > use simpler
> > approaches,
> > even if they are not architecturally pure. Some of these
> > approaches that
> > are available
> > today and won't double the cost of a device because the OAM
> > functions are
> > built
> > on top of existing software, and thus don't require an army
> > of software and
> > hardware
> > developers to realize.
> >
> > I really think that operators and vendors want to
> > eat OAM pudding,
> > not just talk about what color and shape it is. I just think
> > if we try to
> > build the
> > pudding described in Y.1711, that we will all starve
> >
> > > > If there are still holes after this exercise, lets
> work together
> > > > on these problems and find efficient and solvable solutions
> > > > to them. This may not result
> > > > in an architectural correct over-all grand reference,
> > >NH=> Let me paraphrase what you are saying here:
> > >- I assume this remark is suggesting that the
> > requirements given in
> > >draft-harrison-mpls-oam-req-01.txt (and also in Y.1710) is
> > not really what
> > >carriers want, even though they are asking for them, and
> > that Y.1711 is not
> > >a good solution....
> >
> > I do not think that Y.1711 presents good solutions
> > to the problem of
> > OAM. I don't think I am out in left field on this one either.
> > So again, I
> > propose that we work on practical solutions to the problem of OAM
> > for MPLS.
> >
> > --Tom
> >
> >
> >
> >
> >
> > --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of our time.
> >
>
>