Re: [middisc] status?

Hi David, I partially agree, but would suggest to keep the history and context in mind.

Some of the vendors (the ones reading this email!) are cordial enough to consider moving their in-use middlebox discovery options to a properly allocated option.  This option needs to be nice enough in order to convince them to put the effort into moving there.  The engineers understand that this is "the right thing" to do, but the company won't make any money from this, and will have potential compatibility issues as they transition.  Due to this pain, they won't be able to do it simply because there's an RFC, especially if that RFC doesn't meet their business needs.  Those business needs may include carrying opaque bytes of vendor-defined data.

The goal of middisc (and the *need* for it) is to get a spec out that a critical mass of these vendors agree is a feasible/desirable thing for them to use in the future and get them a real option number so that maybe in a decade most of their gear will be using it and we won't discover that half of what we thought were the remaining options numbers have become unusable due to poaching.

TCPM agreed to not resist this effort, though it had no consensus to do it in the working group.  There should be a strong understanding that this is only used for "middlebox discovery" and doesn't provide any other features, but if opaque fields are allowed, then we may not have a whole lot of control over this.  The alternative is to have no control whatsoever and possibly hinder the ability to extend TCP long-term.

________________________________________
From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] On Behalf Of David Harrington [ietfdbh@comcast.net]
Sent: Tuesday, May 24, 2011 9:48 AM
To: 'Andrew Knutsen'; 'Anantha Ramaiah (ananth)'
Cc: middisc@ietf.org
Subject: Re: [middisc] status?

Hi,

> Requirements of this TCP option :
>
> - There has to be a vendor ID (OUI) which would identify the
specific
> vendor. This is needed because every vendors option format is going
to
> be
> different.

This is a recurring theme in my twenty years of IETF work.
The purpose of the IETF is to establish **a standard** so different
vendor's equipment can interoperate.
The purpose of the IETF is NOT to develop a standard that allows every
vendor to do things differently, to not interoperate, yet to be able
to claim compliance to a "standard".

You should be careful about designing a complex solution when a simple
one would do.
It should NOT be a goal to define a standard "bucket" to support
non-interoperable vendor-specific features.
and if you design it that way, you should definitely expect strong
pushback during IESG evaluation.

As I recall, the purpose of this group was to agree on a single
standard option number for middisc, not to design an extensible
approach to vendor-specific options. I see mission creep in this list
of requirements.

A note from the list administrator: this mailing list was created to
allow you guys to resolve the unauthorized use of option numbers for
middisc, preferably by agreeing on a standard option number. The IESG
finds that these non-WG mailing lists can diverge into "shadow working
groups" where the list members think they can devise whole new
features with limited input from the IETF community. That is not the
purpose of this mailing list. If you want to develop a new feature for
TCP, then this should be discussed in a working group. I am asking you
to **focus** on solving the existing problem, which is eliminating the
unauthorized use of option numbers for middisc, not on possible future
extensions.

David Harrington
Director, IETF Transport Area
ietfdbh@comcast.net (preferred for ietf)
dbharrington@huaweisymantec.com
+1 603 828 1401 (cell)

>
> - Already existing non-standardized option numbers (TCP option 33,
> riverbed's options no's) for doing auto discovery should not be
> allocated for this new TCP option. This is to prevent any confusion.
>
> - The TCP option needs to be variable length to permit multiple
option
> formats since the option size may vary depending on the vendor.
>
> - This TCP option should be advocated for use only by middleboxes.
>
> ---------------
>
>      The only changes to these requirements I'm aware of were:
>
> - Make the overhead minimal
>
> - Allow evolution to vendor-independent formats
>
> - Allow options to be sent mid-stream
>
>      These requirements were discussed and led to the current
> proposal.
>
>      The "NAT reveal" option, while intended for consumption by the
> destination server rather than a middlebox, could use the current
> proposed format as far as I can tell (adding 1 or 2 bytes).
> However we
> may want to tighten up the allowed uses a bit, to be more
> specific than
> "used by middleboxes". Perhaps something regarding communicating the

> state of the middlebox, or information which has been hidden by the
> middlebox. (This would permit our and the NAT-reveal uses, as
> far as I
> know).
>
> Andrew
>
>
>
>
> On 11/7/2010 10:32 PM, Anantha Ramaiah (ananth) wrote:
> > Lars,
> >     From my side, it has been real crazy at work and I
> couldn't devote
> > any time for this effort. I did follow the last few email
> exchanges on
> > this. Few thoughts I had in mind was :-
> >
> >   - to have a generic middle box option, which not only
> caters to the
> > needs of middle box discovery, but also to stuff like the
> following :-
> >
> > http://tools.ietf.org/html/draft-wing-nat-reveal-option-00
> >
> > (When I did an internal review of Dan's draft, I had suggested the
> > same.)
> >
> > -  Have a requirements document for the middisc TCP option.
> It appears
> > to me that, there is a need for a precursor document to
> establish some
> > common needs and a rationale for a midisc option. This
> would great help
> > in getting to a faster consensus and would also help some
> new vendors
> > who may be want to join this effort to come to the same
> page as the rest
> > of us.
> >
> > Also, during the initial meeting, I am remembering that you were
> > planning to send an email to the various IETF mailing lists
> citing this
> > effort and asking if there are any other vendors who do
> this middisc and
> > may be interested in joining this effort.. any progress on
> that front?
> >
> > thoughts?
> >
> > Thanks,
> > -Anantha
> >
> >
> > -----Original Message-----
> > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org]
On
> > Behalf Of Lars Eggert
> > Sent: Sunday, November 07, 2010 9:25 PM
> > To: middisc@ietf.org
> > Subject: [middisc] status?
> >
> > Hi, folks,
> >
> > I'm wondering what the status of this effort is - the list has
been
> > silent in the last months.
> >
> > Thanks,
> > Lars
> > _______________________________________________
> > middisc mailing list
> > middisc@ietf.org
> > https://www.ietf.org/mailman/listinfo/middisc
>
> _______________________________________________
> middisc mailing list
> middisc@ietf.org
> https://www.ietf.org/mailman/listinfo/middisc
>

_______________________________________________
middisc mailing list
middisc@ietf.org
https://www.ietf.org/mailman/listinfo/middisc