Subject: [tcpm] TR: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt

From: <[email-masked]>
Date: Wed, 19 Feb 2014 07:50:58 +0100

Dear Michael, 

As promised, please find below answers from the authors of the following implementations to the questions your raised:
* http://www.inet.no/barefoot/doc/1.4.x/config/hostid.html 
* http://www.inet.no/dante/doc/1.4.x/config/hostid.html 

Cheers,
Med

PS: I have one comment about the interop question, this is a key requirement for the case I'm interested in (i.e., address sharing case). The device (host or address sharing) injecting the host_id and the server parsing and interpreting the option are not managed by the same entity. 

-----Message d'origine-----
De : Karl-Andre' Skevik [mailto:[email-masked]] 
Envoyé : mardi 18 février 2014 14:43
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]
Objet : Re: TR: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt

Hello,

To answer the questions:

-We would likely add support for a standardized interface if one was
 available.
-We can likely provide feedback on draft documents.
-Our existing implementation will as far as I know not require
 interoperability with other implementations.

Please let me know if I can be of further assistance.
With kind regards,

Karl-Andre' Skevik
Inferno Nettverk A/S

<[email-masked]> writes:

> Dear Karl'Andre,
>
> In order to progress the host_id TCP option within IETF, the chair of the tcpm WG is raising some questions that I promised to relay to you. The questions are listed below. 
>
> Would you mind if you can answer to those questions? I will relay the answer to the group if required.
>
> Thank you in advance.
>
> Cheers,
> Med
>
> -----Message d'origine-----
> De : tcpm [mailto:[email-masked]] De la part de [email-masked]
> Envoyé : vendredi 14 février 2014 16:06
> À : Scharf, Michael (Michael); Brandon Williams; [email-masked]
> Objet : Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt
>
> Re-,
>
> In fact they support the HOST_ID option in two implementations (a SOCKS proxy and a port bouncer). The second one is available at: http://www.inet.no/barefoot/doc/1.4.x/config/hostid.html. 
>
> I cannot speak on their behalf, but I can get in touch with Karl'Andre and invite him to react in the list.
>
> Cheers,
> Med
>
>>-----Message d'origine-----
>>De : Scharf, Michael (Michael) [mailto:[email-masked]]
>>Envoyé : vendredi 14 février 2014 15:01
>>À : BOUCADAIR Mohamed IMT/OLN; Brandon Williams; [email-masked]
>>Objet : Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt
>>
>>Hi Med,
>>
>>Thanks a lot for the pointer. I was not aware of that.
>>
>>Given my lack of understanding, some questions: Would this implementation
>>probably use a TCPM standard if TCPM started to work on an option? Would
>>the implementers contribute to TCPM, e.g., by reviews and feedback? Does
>>this implementation require interoperability with other implementations?
>>
>>Thanks
>>
>>Michael
>>
>>
>>________________________________________
>>Von: tcpm [[email-masked]]&quot; im Auftrag von
>>&quot;[email-masked] [[email-masked]]
>>Gesendet: Freitag, 14. Februar 2014 12:57
>>An: Brandon Williams; [email-masked]
>>Betreff: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt
>>
>>Dear all,
>>
>>In addition to the three proposals already quoted in the draft, there is
>>also this implementation:
>>http://www.inet.no/dante/doc/1.4.x/config/hostid.html. It relies on another
>>proprietary extension.
>>
>>Cheers,
>>Med
>>
>>>-----Message d'origine-----
>>>De : tcpm [mailto:[email-masked]] De la part de Brandon Williams
>>>Envoyé : mercredi 12 février 2014 20:31
>>>À : [email-masked]
>>>Objet : Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt
>>>
>>>On 02/11/2014 11:12 PM, Wesley Eddy wrote:
>>>> On the topic of WG adoption, I'm not sure why that's needed. The I-D
>>>> exists in the repository, and the ExID is registered ... anyone can go
>>>> play with it. What value is an additional RFC beyond the I-D at this
>>>point?
>>>>
>>>> I say that because while it's nicely written, I don't think the IETF
>>>> should publish a consensus document about hacking little things into TCP
>>>> headers via middleboxes so that other layers can cope. It doesn't solve
>>>> problems with TCP nor problems that TCP causes; the TCP header is just a
>>>> convenient place to stash the bits. This is not something that any
>>>> amount of edits to the document are going to alter :).
>>>>
>>>> That said, if there was a significant mass of the vendors that insist on
>>>> doing this stuff in their products, then it's definitely better to have
>>>> the spec for it done here, ***assuming*** they would actually converge
>>>> on it and not do N different things in conjunction.  The middisc draft
>>>> is a good example ... it made sense to do because several vendors all
>>>> said they could and would move to the common format / option number.  I
>>>> don't know whether that's the case here or not.
>>>>
>>>
>>>Your comment about multiple vendors implementing different mechanisms is
>>>precisely why we would like to get this I.D. published as an RFC, and
>>>also why we would like to get a broader consensus within the tcpm
>>>working group on the draft. Although the three of us are in agreement
>>>about the value of using a common format, we think that getting the I.D.
>>>published will encourage any other vendors who see the need for such an
>>>option to use the common format and abide by the common usage
>>>guidelines. This argument also applies to our desire for WG adoption.
>>>Although the IESG approval process allows the possibility of publishing
>>>an experimental RFC as an independent submission, we think that WG
>>>adoption would help to limit the likelihood of redundant options.
>>>
>>>Of course, the process of at least attempting to move toward WG adoption
>>>also has a value, in that I think it encourages some people on the list
>>>to comment on the I.D. when they otherwise would not have. We're getting
>>>that benefit already, regardless of whether or not we eventually get WG
>>>consensus.
>>>
>>>--Brandon
>>>
>>>--
>>>Brandon Williams; Senior Principal Software Engineer
>>>Emerging Products Engineering; Akamai Technologies Inc.
>>>
>>>_______________________________________________
>>>tcpm mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/tcpm
>>
>>_______________________________________________
>>tcpm mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm