Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC

["t.petch" <[e-mail]>]

----- Original Message -----
From: "Eliot Lear" <[e-mail]>
To: "t.petch" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, March 21, 2012 12:06 PM
> Tom,
>
> I've let this sit a while, but wanted to respond on the following point:
>
> On 3/6/12 4:25 PM, t.petch wrote:
> > -ur responsibility is to ourselves first and foremost, and to see that
> > our process is followed.  That process exists to, amongst other things,
> > insure safe use and interoperable use of our own protocols.
> > Which, Eliot, is where we part company.  Given the interest in and uptake
> > of MPLS outside the original definition, we have a wider responsibility,
> > as we have in, say, managing the IP address or domain name space.
>
> If our process is broken, we should change it.  Our processes should
> take into account that which *we* can control.  Making the best
> recommendations for the use of our protocols on the Internet addresses
> your point about the "wider community".  The IETF exists to serve that
> wider community, but when others attempt to use our works in a way that
> might harm our work, we equally have a responsibility to hold a line.  I
> am NOT saying that in this instance, by the way, G.8113.1 harms IETF
> work if a proper code point is assigned.  It would harm our work if a
> code point was simply expropriated.

<tp>
Yes I agree.

> >   As
> > with the last two, if we do not consider the needs of all parties, and not
just
> > ourselves, we may lose our influence in these matters.  Yes we must follow
our
> > processes but in the interests of a wider community than just ourselves.
>
> Were this really true, then we must reject this request because of the
> likelihood of fragmented solutions that do not interoperate.  Is that
> what you are arguing?

Disagree here.  Where multiple solutions exist, then interoperability costs
more.  Ask anyone implementing ... well anything with IP in it, say, and
currently, they will be expected to have both IPv4 and IPv6, a dual stack in
some sense of the word, and the cost of this ripples up the stack to whereever
IP addresses cease to be visible, which is a long way up.

Ditto SNMP where there are three different flavours that a stack will support,
in many if not most cases.  And so on and so forth.

So having two different packet formats for the same OAM function is a pain and
will cost; but as long as the protocols are properly defined, as I believe they
are here, then the coexistence will have a cost but will not stop
interoperability, in the same way as we have IPv6 and IPv4 and a lot of
associated options, dual stack, gateway, encapsulation ......

Tom Petch

>
> Eliot
>