Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

Jordi,

Where have you got the idea that an implementation of 6RD also supports Configured tunnels?
That is wrong.

Ole

> On 13 Apr 2017, at 11:05, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
> 
> Hi Mikael,
> 
> No, it is actually much easier than that. The text I proposes will go to the same section (6in4). So, it will be (for the sake of clarity):
> 
> 5.4.2.  6in4
> 
>   6in4 [RFC4213] specifies a tunneling mechanism to allow end-users to
>   manually configure IPv6 support via a service provider's IPv4 network
>   infrastructure.
> 
>   The CE router MAY support 6in4 functionality.  If 6rd is implemented,
>   6in4 is already supported as well, as the underlying protocol/technology
>   is the same, being the only difference, having the mention of “6in4” in
>   the GUI/CLI (just an example) if it is being configured manually, or
>   even stating that in the relevant documentation. In other words, no
>   additional code is required for the support of 6in4 when 6rd is already
>   supported. If 6in4 is supported, it MUST be implemented according to
>   [RFC4213].  The following CE Requirements also apply:
> 
> …
> 
> No code is required at all, and in any case, the target is MAY, same as we have it right now also for 6rd. Let me explain.
> 
> Let’s suppose you have *any* router or OS with 6rd support, never mind the configuration is done by means of DHCP or user-entered configuration (as you said original 6RD-2, but also 6RD-1 and 6RD-3), and instead of a 6RD relay, you provide the 6in4 tunnel-end-point, it just works.
> 
> It is simple to understand, because both, 6in4, 6to4, and 6rd, actually do exactly the same encapsulation/decapsulation (protocol-41), and exactly the same routing thing. The difference is that in 6in4 is called a tunnel broker (or similar), in 6to4 is a 6to4 relay, etc. All the parameters in the UI are the same.
> 
> What it means from the perspective of the CE implementer: only a minor text change in the UI. The UI today has a “menu” to allow 6RD-2 config, that says “6rd”. What I’m saying is it to be changed to say “6rd/6in4” or alternatively, one option for “6rd” and another for “6in4”, but actually both choices will bring to the same “code”.
> 
> I believe Barbara is worried that if I keep it as a different than 6rd transition mechanism (as it is actually in the current -01 version, see section 5.4.2), because I’m referring to RFC4213, I’m “adding” more requirements behind that RFC. I’m actually reading all those documents and I believe she is wrong on that, but I will answer that in a few minutes.
> 
> I see no “technical” difference in having it as part of the 6rd text or as it is right now a separated one, which seems to me (I think you agree on this, if I understood correctly) your email, clearer.
> 
> Regards,
> Jordi
> 
> 
> -----Mensaje original-----
> De: Mikael Abrahamsson <swmike@swm.pp.se>
> Organización: People's Front Against WWW
> Responder a: <swmike@swm.pp.se>
> Fecha: jueves, 13 de abril de 2017, 10:32
> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> CC: "v6ops@ietf.org" <v6ops@ietf.org>
> Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
> 
>    On Wed, 12 Apr 2017, JORDI PALET MARTINEZ wrote:
> 
>> The CE router MAY support 6in4 functionality.  If 6rd is implemented,
>> 6in4 is already supported as well, as the underlying protocol/technology
>> is the same, being the only difference, having the mention of “6in4” in
>> the GUI/CLI (just an example) if it is being configured manually, or
>> even stating that in the relevant documentation. In other words, no
>> additional code is required for the support of 6in4 when 6rd is already
>> supported
> 
>    In the original 6RD-2 requirement that talks about user configuration, for
>    configuring 6in4 the UI would need to look slightly different, right?
>    Depending on some choices in UI, some input methods of the parameters
>    might not work with 6in4.
> 
>    So I guess your intention to include 6in4 could be done either as a new
>    transition protocol with SHOULD, or it can add an additional MAY
>    requirement in 6RD that the settings be compatible for configuring a
>    generic 6in4 tunnel as well. The above text seems to be the latter?
> 
>    I think it would actually make more sense to create a "new" transition
>    technology in there in that case. That would keep it clean the way I
>    interpret Barbaras intention is?
> 
>    --
>    Mikael Abrahamsson    email: swmike@swm.pp.se
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

Attachment: signature.asc