Re: [Softwires] ds-lite tunnel option

[JiangSheng 66104 <[e-mail]>]

Tomasz,

I guess you don't understand how IETF WGs work as a new comer. After drafts were submitted to a WG, it is the WG (means majority consensus) to decide how these works continue. You can express your personal opinions, but please do not ignore what the others said.

For my understanding, the members of softwire WG think a generic tunnel discovery mechanism as a extensible container is useful. There are two concerns: 1. if the generic mechanism takes long time to be consensus, some ungent requirements, such as DS-Lite, may have nothing to use; 2. in order to be really generic, the investigation should be done carefully to cover most, if not all, requirements; and at least some DHCP expert from DHC WG should be involved.

So, for me, we should do the generic tunnel discovery mechanism, but move fastly.

Best regards,

Sheng

----- Original Message -----
From: Tomasz Mrugalski <[e-mail]>
Date: Wednesday, July 29, 2009 11:52 pm
Subject: [Softwires] ds-lite tunnel option
To: [e-mail]

> Hi,
> 
> 
> From what I understood during today's meeting discussion, there 
> are 2 goals
> that we are trying to achieve:
> 
> 
> - Standarized option is urgently needed, so we should not prolong the
> discussion more than necessary
> 
> - Generic purpose tunneling and encapsulation approach was 
> discussed before
> without any noticeable agreements
> 
> 
> We have basically 2 proposals (Another proposed option mentioned in
> draft-townsley-ipv6-rd6-00 is designed for DHCPv4, thus not 
> applicable for
> this discussion):
> 
>   1. Dual-Stack Lite option, proposed in
>   draft-dhankings-softwire-tunnel-option-03. This is a simple 
> solution,   designed specifically for addressing dual-stack lite 
> tunnel configuration
>   (IPv4-over-IPv6). There are 2 independent implementations of 
> that proposal
>   available (ISC and dibbler, both open source).
>   2. SC Discovery option, proposed in draft-guo-softwire-sc-
> discovery-01.
>   The second proposal attempts to address generic tunnel 
> configuration, over
>   IPv4 and IPv6 as well. Two options (one for DHCPv4 and one for 
> DHCPv6). Its
>   generic approach comes at a cost. With 3 different fields for type
>   specification and preference, the total number of fields is 7, plus
>   additional possible sub options. Although 3 type fields (SC 
> type, Tunnel
>   Type and Protocol Type) give great flexibility, significant 
> part of all
>   possible combinanations is irrelevent or plain wrong. Therefore 
> number of
>   actual legal combinations is quite limited. Also, there is no
>   implementation.
> 
> There is also certain confusion regarding the sc-discovery draft. -
> 00 was
> presented during meeting, but there is -01 version available. The only
> noticeable change is Protocol Type field being extended to 16 bits and
> ETHER-TYPE values are used.
> 
> 
> 
> Taking into consideration that there was a comment by an Internet Area
> Director that DHCPv4 options specification is no longer a 
> priority, I
> propose to continue working on Dual-Stack Lite option, but to use 
> some ideas
> from SC Discovery option. As dual-stack lite is a IPv4/IPv6 only, 
> there is
> no need to specify tunnel type. Also, this will avoid confusion 
> for vendors
> if there are multiple encapsulations required. No, there is just 
> single one:
> IPv4/IPv6 only.
> 
> 
> Should more generic tunneling configuration mechanism become required,
> additional suboptions may be defined in the future.
> 
> 
> 
> What are group's thoughts regarding that matter?
> 
> 
> 
> If there is a contributting co-author position available, I would 
> be happy
> to volunteer.
> 
> 
> 
> Regards,
> 
> Tomek
>