Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item

From: Caitlin Bestler <[email-masked]>
Date: Wed, 09 Dec 2009 12:39:05 PST

(2) the Middlebox Discovery Option SHOULD NOT become a TCPM working   group document

As stated in the Abstract, "The option has no effect if an appropriate middlebox is not on the path".

As drafted this is not a proposal for "middlebox" discovery, but a method for vendor-specific
clients to find vendor-specific middleboxes.

There is value in having a discovery protocol that follows the same path that any TCP segment
would follow. However, because the TCP option space is limited, such an option should only
be considered when it defines a method of being discovered that *any* middlebox could
support. Then it would be useful as a general network diagnostic tool, and not merely the
specialized uses described in the current draft.

Caitlin Bestler
[email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Wed, 9 Dec 2009 11:47:26 -0900

> (2) the Middlebox Discovery Option SHOULD NOT become a TCPM  

[ ... ]

> but a method for vendor-specific

Hear, hear.

> would follow.

I'd extend that to any IP packet.  Doing it in-band
with TCP is easier than doing it more generally, but
probably the most common place to run into middlebox
issues is with media (UDP) streams used with session-
oriented protocols.  Maybe a v6 header option.

Melinda

---

From: Andrew Knutsen <[email-masked]>
Date: Wed, 09 Dec 2009 13:00:36 -0800

A standard device capability code could be defined for "*any*" 
middlebox.  However the ability to discover devices with particular 
capabilities is also useful/needed, and until those types are 
standardized they will all be vendor-specific.  One step at a time.

Andrew

Caitlin Bestler wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Andrew Knutsen <[email-masked]>
Date: Wed, 09 Dec 2009 13:02:52 -0800

The draft discusses why this must be a TCP option.  An IP option 
could also be defined, but it would address a different problem.

Andrew