RE: draft-bonica-tunneltrace-02

[neil.2.harrison@bt.com]

Eric....can I please ask that you separate slagging-off of the ITU from the
issues.....you do eventually get back to reason I note.  If you want to air
your own prejudices, lack of understanding of the issues being discussed and
have a rant about the ITU then that's OK, but it does not really help
anyone.  Many of your company's customers actually have great respect for
ITU transport Recs, and your own company's success is largely predicated on
the fact that operators have built massive transport networks which are used
to interconnect your company's boxes and create a network....IP on it's own
can't get between boxes, it does need something underneath it.

BTW - The 'arcane' layered network ITU Rec I assume you are alluding to (and
Shahram actually did not) is G.805.....this Rec just states fact (but does
so in a common/rigorous language that many operators/vendors found necessary
to formulate), and there are many manufacturers/operators out there who (i)
helped develop this Rec and (ii) use it to ensure functional architecture
implementations (inter)work/make-sense.  I personally know many of the
engineers who did this work, and let me assure these people are not
stupid...OK?  If you have a problem with this fact that is *your* problem
not the ITU's, not the IETF's and certainly not Shahram's.  So please
exercise some restraint on this ITU bashing as it does you no credit at all.

regards, Neil

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: 28 February 2002 14:59
> To: Shahram Davari
> Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org
> Subject: Re: draft-bonica-tunneltrace-02 
> 
> 
> 
> Shahram> It  has serious  security, complexity,  backward  
> compatibility and
> Shahram> layer violation issues.
> 
> Tom> Can you elaborate on what you think these are? 
> 
> Shahram> Please refer to previous emails by me and David 
> Allan. Most of them
> Shahram> are listed there.  
> 
> I'm sorry, but  as far as I  can tell, those previous mails  
> simply say that
> (a)  the  proposed  solution doesn't  do  some  things  that 
> you  think  are
> valuable,  and (b)  the proposed  solution doesn't  fit well  
> into  some ITU
> architecture.
> 
> The  second  of  these  points  is  completely  irrelevant.   
> The  first  is
> irrelevant too, unless there is a reasonable alternative 
> proposed which does
> more,  or if the  current proposal  doe so  little that  SPs 
> don't  think it
> worthwhile.   The MPLS OAM  stuff you've  been pushing  is 
> not  a reasonable
> alternative of  this sort  because (a)  it is MPLS-specific,  
> and (b)  it is
> already crystal  clear that it will not  be accepted in the  
> IETF.  And it's
> pretty clear  that a number of SPs  do think that what  the 
> current proposal
> does is worthwhile.
> 
> If  you can actually  cite specific  security issues  with 
> the  proposal, it
> would be valuable to know about them. 
> 
> Suggestions for reducing complexity would  also be valuable, 
> if you have any
> specific suggestions in that area. 
> 
> I don't understand what the backwards compatibility issue is, 
> as there is no
> previous version to be compatible with.
> 
> If you think there  are layer violation issues, then what you 
>  need to do is
> exhibit the particular set of  specific problems that will 
> arise in practice
> as a result of those violations.   If you cannot do this 
> without referencing
> some arcane ITU  architecture document, then the natural  
> conclusion is that
> the  problem  is with  that  architecture's  layering  model, 
> not  with  the
> proposal.
> 
> 
> 
> 
>