Subject: Re: [Mip6] RE: concensus on [issue94] fixing encapsulation mechanism in IPv4 network

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 3 Apr 2007 14:29:51 +0900

Hello Basavaraj,

On 2007/03/31, at 5:28, Basavaraj Patil wrote:

>> I think you are explaining the reason why we can allow IP-in-IP
>> tunnel mode.  I have never said to disallow IP-in-IP mode.  Your
>> implementation can still use both IP-in-IP, IP-in-UDP of course.
>
> Okay... So you agree that depending on the scenario you could use  
> either
> IP-in-IP or IP-in-UDP, right?

My idea is that UDP tunnel mode can be used in all the cases, but in  
some cases, we can use IP tunnel mode that consumes less bits.

>> What I was asking was the technical reason why you want to reject UDP
>> tunnel only mode.
>
> UDP tunnel only mode is less optimal than IP-in-IP.
> The MN should (or MUST) be able to support both tunnelling schemes.  
> Why
> would you restrict the MN to only using IP-in-UDP in all cases?

I think there is pros and cons.  UDP tunnel consumes more bits, I  
agree.  But it can be operated in some environment where IP tunnel  
mode cannot be used.  I think UDP tunnel mode can cover all the  
environment that IP tunnel mode covers.  So in the sense of the cove  
area, UDP tunnel mode is a superset of IP tunnel mode.

Considering that, I think it is not so strange that there is a  
request that wants to implement UDP tunnel only mode.

>> As I said, introducing the 'U' flag (or in other words, RFC3519 style
>> 'F' flag) allows some limited implementation (UDP only
>> implementation).  Such implementations are still interoperable with
>> full (both IP tunnel and UDP tunnel) implementations.
>
> And so far at least the consensus from what I can tell is to have  
> the HA
> decide what encapsulation mode to use. Hence if you have an MN that  
> only
> implements IP-in-UDP and the HA rejects such encapsulation mode,  
> the MN is
> pretty much out-of-luck. And as has been mentioned the MN cannot  
> command the
> HA to honor its request for IP-in-UDP encapsulation. The decision  
> point is
> the HA and lets stick with that design approach.

Rejecting UDP tunnel mode is one choice of the business operation  
choices.  I don't oppose that some operators take the choice.  But if  
they accept MNs that implements UDP tunnel only mode, then they will  
get more customers.

>> I simply don't understand why we cannot allow such implementation.
>> I'm proposing to keep the current functions completely, and
>> requesting to allow some limited implementation which is still
>> interoperable.
>
> What you are requesting is that if the MN were to request IP-in-UDP
> encapsulation, the HA MUST honor it. Otherwise there is no  
> interoperability
> with the HA since the MN does not implement IP-in-IP encapsulation.

I think this is the point that we don't understand each other.  You  
think all operators and MN vendors want to use IP tunnel mode for  
saving bits.  I think some operators and MN vendors may want all UDP  
tunnel mode.

> What is your main argument about or use-case/scenario where you  
> have this
> limited implementation (IP-in-UDP only encapsulation) MN?

Implementation can be simpler.

1) MN can have only two tunneling functions, one is IPv*-in-IPv6 and  
IPv* in UDPv4, rather than having IPv*-in-IPv4, IPv*-in-IPv6 and IPv*- 
in-UDPv4.  As Romain Kuntz reported in other mail, having more  
tunneling mechanisms may not be a big work in Linux, but there is a  
system it is.

2) MN can only provide switching between only two tunneling methods  
rather than switching between the three mechanisms.

> I guess you do actually have limited interoperability because if  
> the MN
> requests IP-in-UDP encapsulation you have a 0.5 probability that  
> the HA will
> accept it. So you have interoperability possibility 50% of the time  
> and when
> the HA rejects it, well... No connectivity.

Can't we do the similar approach that RFC3519 does?  That is, the HA  
basically accepts the UDP tunnel request.  Since the HA can accept  
MNs that don't request any tunneling preference, it will not lose any  
existing MNs.  In addition to this, the HA can have more MNs that  
have limited tunneling function.

Regards,
---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
WIDE Project <[email-masked]>

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6