RE: draft-bonica-tunneltrace-02

[neil.2.harrison@bt.com]

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