Subject: [middisc] status?

From: Lars Eggert <[email-masked]>
Date: Mon, 8 Nov 2010 13:25:18 +0800

Hi, folks,

I'm wondering what the status of this effort is - the list has been silent in the last months.

Thanks,
Lars

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 7 Nov 2010 22:32:55 -0800

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Lars Eggert
Sent: Sunday, November 07, 2010 9:25 PM
To: [email-masked]
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

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Sun, 7 Nov 2010 22:44:53 -0800

I have been pulled off to work on other projects and have not been able
to spend time on this.  However, the other Blue Coat authors are still
working in this area and should be able to comment from our side.

--Jamshid 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anantha Ramaiah (ananth)
Sent: Sunday, November 07, 2010 10:33 PM
To: Lars Eggert; [email-masked]
Subject: Re: [middisc] status?

Lars,

thoughts?

Thanks,
-Anantha

-----Original Message-----

Hi, folks,

Thanks,
Lars
_______________________________________________
middisc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/middisc

---

From: "Li, Qing" <[email-masked]>
Date: Sun, 7 Nov 2010 23:28:38 -0800

I am at the IETF so do you guys want to get together
and discuss the next step?
 
-- Qing

________________________________

From: [email-masked] on behalf of Mahdavi, Jamshid
Sent: Sun 11/7/2010 10:44 PM
To: Anantha Ramaiah (ananth); Lars Eggert; [email-masked]
Subject: Re: [middisc] status?

--Jamshid

-----Original Message-----

Lars,

thoughts?

Thanks,
-Anantha

-----Original Message-----

Hi, folks,

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 8 Nov 2010 15:41:33 +0800

> may be interested in joining this effort.. any progress on that front?

No. The discussion was quite intense a few months back and I wanted to wait until at least this little ad hoc group was on the path to convergence...

Lars

---

From: Andrew Knutsen <[email-masked]>
Date: Mon, 08 Nov 2010 11:01:39 -0800

Mark, Ron and I had pretty much settled on a proposal a few months 
ago, but unfortunately I got busy elsewhere and haven't written it up as 
a draft.  I'm assuming this will be a different draft from the TCPM one 
that is currently expiring.  I've attached Ron's email with the current 
proposal.

Andrew

> No. The discussion was quite intense a few months back and I wanted to wait until at least this little ad hoc group was on the path to convergence...

Subject: Re: [middisc] Poll re vendor ID format
From: "Ron Frederick" <[email-masked]>
To: "Mark Day" <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 1 Jul 2010 17:37:35 -0800
List-Id: "Discussions on TCP option for middlebox discovery."<middisc.ietf.org>

On Jun 30, 2010, at 11:23 AM, Mark Day wrote:

	Yes, I guess so.  Not exactly elegant conceptually, I admit. 
	 
	But if the goal is to have the type byte in a predictable place across all standard, vendor-ID & OUI usages, while minimizing the number of bytes of mandatory overhead, I think it’s the right solution. 

While it's not ideal, I can live with it. So, to summarize, I think we're proposing the following alternatives as supported:

Case 1:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Opt kind=TBD  |    Opt len    | Vendor = 0x00 | Std type code |
+---------------+---------------+---------------+---------------+
|                                                               |
| ... Optional standard payload data dependent on type code ... |
|                                                               |
+---------------+---------------+---------------+---------------+

Case 2:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Opt kind=TBD  |    Opt len    | Vendor = 0xFF | Vend typecode |
+---------------+---------------+---------------+---------------+
|              Vendor OUI (3 bytes)             |               |
+---------------+---------------+---------------+               |
|                                                               |
| ...Optional vendor payload data dependent on vend typecode... |
|                                                               |
+---------------+---------------+---------------+---------------+

Case 3:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Opt kind=TBD  |    Opt len    | Vendor=Other  |               |
+---------------+---------------+---------------+               |
|                                                               |
| ...Optional vendor payload data dependent on vend typecode... |
|                                                               |
+---------------+---------------+---------------+---------------+

In case 3, the byte following the Vendor field SHOULD be a vendor type code, as shown in case 2. However, vendors MAY encode option type information in other ways for their specific vendor code.

Is everyone ok with this?
-- 
Ron Frederick
[email-masked]

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 8 Nov 2010 11:30:17 -0800

Andrew,

       I think my comment here is that the option format needs to as
generic as possible to accommodate other use cases. I had posted another
example (NAT reveal option which is is being proposed).  I have the
following suggestions/comments :-

-          I think it would be expedient to produce a requirements
document. This is very useful to keep many folks on the same page and
will be useful when the  TCP option gets discussed.  

-          do we want a middlebox discovery option OR a generic Proxy
option which can cover other use cases?

-          Would IANA manage the vendor ID's ? 

Thanks,

-Anantha

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andrew Knutsen
Sent: Monday, November 08, 2010 11:02 AM
To: Lars Eggert
Cc: [email-masked]
Subject: Re: [middisc] status?

Andrew

	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?

No. The discussion was quite intense a few months back and I wanted to
wait until at least this little ad hoc group was on the path to
convergence...
 
Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 9 Nov 2010 09:20:38 +0800

Hi,

On 2010-11-9, at 3:30, Anantha Ramaiah (ananth) wrote:
>       I think my comment here is that the option format needs to as generic as possible to accommodate other use cases. I had posted another example (NAT reveal option which is is being proposed).

we can certainly discuss whether other uses under the umbrella of "middlebox discovery" should be possible with this option.

But I want to stress that the intent here is specifically *not* to set aside a codepoint for arbitrary vendor extensions of TCP.

Lars

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 09 Nov 2010 15:37:46 -0800

In May, Anantha suggested the following:
---------------

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.

- 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