[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-bonica-tunneltrace-02
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. 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. However, you are not compelled to implement all (or
even any) of this stuff if you choose not to.
> and b) can be sold for a
> reasonable price.
> If neither
> can be met, then we are all just wasting our time.
NH=> What is a reasonable price to your company wrt to a box may mean an
unreasonable price/risk to an operator wrt to a network and the services it
supports, ie the operator may have increased Opex costs and unhappy
customers because they cannot offer robust carrier-strength network/service
management. It would really help if you could give us some hard proof that
what has been requested/proposed is too costly for us/you? But so far it
seems I can't get answers to this.
<snipped>
> I think what might be more constructive is to set out the
> current problems that you as an operator (and other
> operators) think need
> to be
> solved and then see how the existing solutions can be used to
> solve these
> problems.
NH=> I though we did this at the last BoF?....Peter Willis represented BT
and gave these. They are stated (as requirements) in
draft-harrison-mpls-oam-req-01.txt.
> 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? 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.
> 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....so, as I have asked many times now, it would help if you
could please provide evidence to support this remark.
- irrespective of what carriers want, it seems the answer is X, so
let's develop X and only X come what may. Given this, is there actually any
point is submitting requirements?
> but it
> is probably
> going to get us further
> than arguing over what is architecturally pure and what is
> not, which IMHO
> is a waste
> of everyone's time.
NH=> Agree with the waste of everyone's time bit......IMO it hardly seems to
matter what certain carrier's bring to IETF, it seems they just get ignored
if it does not suit certain parties. Indeed, we are seriously reviewing the
value of continued IETF participation because of this. I think it would be
far more constructive if you could explain to the carriers noted above why
they don't really want what they are asking for. It would also help if you
can explain how the 'existing solutions' (sic) that you refer to can meet
(or not) these requirements?
However, if you are not even prepared to countenance such requirements as
you stated above (ie "Please don't just refer us again to your OAM draft,
because I think it is clear that is a non-starter."), then maybe the simple
way out now (esp so we don't continue to waste each others time) is that
'IETF' develop the OAM solutions for MPLS that they feel are fit for purpose
and we let the carriers choose what they want to ask for? And, as I
remarked earlier, there is no need whatsoever for your company to implement
all (or even any) of the Y.1711 stuff if you don't feel its any good.