RE: draft-bonica-tunneltrace-02

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Tom,

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

Simpler and scalable such as GTTP?!!!!!!!!!! very interesting?

> more practical mechanisms. These same vendors and 
> operators alike
> spoke out at the OAM BOF against your grand architecture of 
> OAM for this
> reason.

To my knowledge only 3 opertors spoke against, which one of them
does not exist any more (bankrupted). That leaves us with 2 operators against
and 6 opertors for MPLS OAM!!!!!!!!!! 

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

Could you please name those carriers and their rational?

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

Interesting. So you actually beleive that MPLS OAM doubles the cost of device!!!

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

Why?

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

Why? The approach taken in Y.1711 is not new, it has been around for
many many years in other technologies and has proven to work fine.

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

What do you mean by practical solution? 

-Shahram

> 
>          --Tom
> 
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 
>