Subject: [middisc] TCP middlebox option - Revisted.

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sat, 14 May 2011 19:23:39 -0700

Guys,

     During the last IETF,  we  (Steven from Riverbed and myself)
briefly chatted with Wes (the new transport AD) . Following needs to
happen to move forward :-

-          We agree upon the option format. 3 choices were proposed.
>From my pov, I would stick with the one that is most generic since there
is more flexibility and can easily accommodate multiple vendor option
formats.

-          The draft needs some upgrade in terms of describing the
problem scope/requirements, add motivation section,  interoperability
with other TCP options etc., and just list the option format for which
we all agree upon.

-          The draft needs to have contributors (or authors) from each
vendor, Bluecoat, Riverbed, Cisco and if possible Citrix.  This way it
simply reflects that this is joint effort . 

-          Then we can submit this to IESG/IANA and request for the
option allocation.

Actually it has been a while and it was kind of low priority for all of
us, but since we all started with a intention of getting the TCP option
allocated , I am thinking that there is no point in losing the momentum.

-Anantha

---

From: Wesley Eddy <[email-masked]>
Date: Sat, 14 May 2011 23:16:26 -0400

On 5/14/2011 10:23 PM, Anantha Ramaiah (ananth) wrote:
> Guys,
>
> During the last IETF, we (Steven from Riverbed and myself) briefly
> chatted with Wes (the new transport AD) . Following needs to happen to
> move forward :-
>
> -We agree upon the option format. 3 choices were proposed. From my pov,
> I would stick with the one that is most generic since there is more
> flexibility and can easily accommodate multiple vendor option formats.
>
> -The draft needs some upgrade in terms of describing the problem
> scope/requirements, add motivation section, interoperability with other
> TCP options etc., and just list the option format for which we all agree
> upon.
>
> -The draft needs to have contributors (or authors) from each vendor,
> Bluecoat, Riverbed, Cisco and if possible Citrix. This way it simply
> reflects that this is joint effort .
>
> -Then we can submit this to IESG/IANA and request for the option allocation.
>

Thanks for sending this.

Just one small clarification: I will AD-sponsor this, so I will
initiate the IESG review when it's ready.  IANA will look at it at
that point.  The authors do not need to submit anything to the
IESG or IANA themselves in regards to publishing this draft.

-- 
Wes Eddy
MTI Systems

---

From: Mark Day <[email-masked]>
Date: Sun, 15 May 2011 14:09:32 -0700

Hi Anantha,

Thanks for restarting the thread.  I'm keen to get going on the tasks you outline.

My personal opinion is that it would actually be easier and more straightforward to write a new draft capturing the state of the discussion at the point where things petered out, rather than trying to adjust the existing draft which was originally written with a somewhat different goal.  However I'm mostly interested in making progress and so I'm happy to back off that opinion if people are keen to move the previous draft forward.

Thanks,

--Mark

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anantha Ramaiah (ananth)
Sent: Saturday, May 14, 2011 10:24 PM
To: [email-masked]
Cc: Wesley Eddy; Steven Campbell
Subject: [middisc] TCP middlebox option - Revisted.

Guys,
     During the last IETF,  we  (Steven from Riverbed and myself) briefly chatted with Wes (the new transport AD) . Following needs to happen to move forward :-

-          We agree upon the option format. 3 choices were proposed.  From my pov, I would stick with the one that is most generic since there is more flexibility and can easily accommodate multiple vendor option formats.

-          The draft needs some upgrade in terms of describing the problem scope/requirements, add motivation section,  interoperability with other TCP options etc., and just list the option format for which we all agree upon.

-          The draft needs to have contributors (or authors) from each vendor, Bluecoat, Riverbed, Cisco and if possible Citrix.  This way it simply reflects that this is joint effort .

-          Then we can submit this to IESG/IANA and request for the option allocation.

Actually it has been a while and it was kind of low priority for all of us, but since we all started with a intention of getting the TCP option allocated , I am thinking that there is no point in losing the momentum.

-Anantha

---

From: Andrew Knutsen <[email-masked]>
Date: Mon, 16 May 2011 11:24:19 -0700

I'm glad to see interest again too.  Every time we do a rev to our 
protocol, I regret missing the chance to change the code.

    I agree we should do a new draft.  It seems like the consensus was 
to reduce the amount of specification of the use of the option to the 
absolute minimum needed to avoid its use as a "catch-all".

    I've attached Ron's last proposal.  Hopefully we can start from there.

Andrew

On 5/15/2011 2:09 PM, Mark Day wrote:
> My personal opinion is that it would actually be easier and more 
> straightforward to write a new draft capturing the state of the 
> discussion at the point where things petered out, rather than trying 
> to adjust the existing draft which was originally written with a 
> somewhat different goal.  However I'm mostly interested in making 
> progress and so I'm happy to back off that opinion if people are keen 
> to move the previous draft forward.
>
> Thanks,
>
> --Mark
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Anantha Ramaiah (ananth)
> *Sent:* Saturday, May 14, 2011 10:24 PM
> *To:* [email-masked]
> *Cc:* Wesley Eddy; Steven Campbell
> *Subject:* [middisc] TCP middlebox option - Revisted.
>
> Guys,
>
> -We agree upon the option format. 3 choices were proposed.  From my 
> pov, I would stick with the one that is most generic since there is 
> more flexibility and can easily accommodate multiple vendor option 
> formats.
>
> scope/requirements, add motivation section,  interoperability with 
> other TCP options etc., and just list the option format for which we 
> all agree upon.
>
> Actually it has been a while and it was kind of low priority for all 
> of us, but since we all started with a intention of getting the TCP 
> option allocated , I am thinking that there is no point in losing the 
> momentum.
>
> -Anantha
>
>
> _______________________________________________
> middisc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/middisc

Subject: Fwd: [middisc] Poll re vendor ID format
From: Ron Frederick <[email-masked]>
To: Andrew Knutsen <[email-masked]>
Date: Tue, 20 Jul 2010 14:16:20 -0700

This was the last message -- I never got a reply from anyone on this.

Begin forwarded message:
> From: Ron Frederick <[email-masked]>
> Date: July 1, 2010 6:37:35 PM PDT
> To: Mark Day <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [middisc] Poll re vendor ID format
> 
> 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]