Subject: RE: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensuscalltoclose issue 93

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 4 Jul 2007 09:57:22 +0200

Hi Sri:

We went through this KA discussion. Even discussed having an async
message sent by the HA with a short TTL or something so that it would
pass the NAT but not reach the MN, so the MN could be left sleeping and
save battery. But at the end of the day, BU/BA seemed to do the job
quite fine, bringing the value of revalidating the BCE when a simple
ping would be total loss.

Do you have an issue with that? On which side?

Pascal

>-----Original Message-----
>From: Sri Gundavelli (sgundave)
>Sent: Tuesday, June 26, 2007 9:29 AM
>To: 'Jari Arkko'
>Cc: [email-masked]; 'Mobile IPv6 Mailing List'; 'Henrik Levkowetz';
'Basavaraj Patil'
>Subject: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 -
Consensuscalltoclose issue 93
>
>Hi Jari,
>
>
>> -----Original Message-----
>> From: Jari Arkko [mailto:[email-masked]]
>> Sent: Friday, June 22, 2007 2:03 AM
>> To: Sri Gundavelli
>> Cc: 'Basavaraj Patil'; 'Henrik Levkowetz'; [email-masked];
>> 'Mobile IPv6 Mailing List'
>> Subject: Re: [Mip6] Summary and conclusion of: DS-MIP6 -
>> Consensus calltoclose issue 93
>>
>> Sri,
>>
>> > 4. Tunnel Keep Alive message
>> >
>> > When DSMIP chose IPv4 UDP transport for NAT traversal,
>> > the need for keepalive messaging between the tunnel
>> > peers for keeping the NAT bindings came up. The authors
>> > of the draft chose to use MIP6 signaling messages BU/BA
>> > as a way to refresh the keepalive messages. IMO, having
>> > a simple keepalive messages is lot more useful than an
>> > expensive BU/BA. Most 3519 implementation today optimize
>> > on this, by eliminating the keepalives when there is
>> > traffic. We cant do such optimizations with BU/BA.
>> >
>>
>> I don't see why not. First of all, you can always skip
>> a keepalive when there is other traffic. Secondly, you
>> can skip the entire contents and send an empty container.
>> Etc.
>>
>
>That's what I meant, when using a KA message, it can always
>be skipped when there is traffic. The KA processing is not
>expensive as compared to the use of BU/BA for the same purpose.
>
>
>> > 6. Why do we need GRE Header ?
>> >
>> > We need GRE tunnel header for various reasons, when ever we
>> > carry multiple streams within a tunnel, the GRE header for its
>> > mature header semantics, the key field and the sequence number
>> > field is useful.
>> >
>>
>> Hmm. Reading on...
>>
>> > We have some NEMO use cases where we use the GRE key to tag
>> > certain MNP flows, and the tunnel peers use these keys as a
>> > form of a selector for differential treatment. Its a color
>> > code.
>> >
>> > Use cases:
>> >
>> > a.) Overlapping private IPv4 addressing support on the MAGs
>> >     (PMIP6 Usage)
>> >
>>
>> From your list, this sounds like the most valid reason. But are
>> there other ways to deal with this? Can you expand on the
>> requirement and describe why there are no other ways to
>> deal with it?
>>
>
>This is for supporting the overlapping private IPv4 address
>scenario. As Vijay was saying, GRE is the most simplest way
>to solve this. It has the proper semantics in the header,
>such as GRE key etc. There are many MIP4 implementations that
>use this mechanism for tagging the flows between the PDSN and
>the HA.
>
>
>> > c.) Carrying other protocol packets (Lets say, IPX packets)
>> >     in a MIP tunnel.
>> >
>>
>> This is not a very convincing use case. We can always encapsulate
>> L2TP etc. inside if we really want to.
>>
>
>The scenario was about using about using MIP tunnel for routing
>other traffic. L2TP cant be used, as it wont provide mobility.
>
>Regards
>Sri

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 4 Jul 2007 01:38:47 -0700

Hi Pascal,

> From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
> Sent: Wednesday, July 04, 2007 12:57 AM
> To: Sri Gundavelli (sgundave); Jari Arkko
> Cc: [email-masked]; Mobile IPv6 Mailing List; Henrik 
> Levkowetz; Basavaraj Patil
> Subject: RE: [nemo] RE: [Mip6] Summary and conclusion of: 
> DS-MIP6 - Consensuscalltoclose issue 93
> 
> Hi Sri:
> 

My concern with the use of BU/BA message as a tunnel keep alive
mechanism is the processing load on the HA. The amount of checks
the BU message will go through is lot more than a normal keepalive
message would go through, in most implementations, IMO. Each time
a BU is processed, the home agent needs to search for the BCE in its
table for that node and update the lifetime. For a simple keepalive,
this entire search can be skipped, its just a echo back and further
the message can be skipped when there is data traffic. If the home
agent is hosting like 1 to 2 million bindings, we need to pay bit
more attention to this. But, if you guys already thought about this
issue and if you are convinced, the processing load on the HA for a
BU vs a simple KA message is just the same, no issue from my side.

Regards
Sri

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 5 Jul 2007 14:46:30 +0200

Hi Sri:

That's fine, then. I agree there is additional processing on a BU but
then, this revalidates the cache so you get value for the relatively low
CPU increment on the overall message processing from the device driver
up. 

How often should a BCE be refreshed? How long should a HA keep sending
packets in the void because it does not know the MN is unreachable at
this old CoA? If your deployment permits, that time should be kept short
enough. If it is in the order of a minute, the BU exchange should ensure
that the NAT state is maintained at no additional cost.

That's the tradeoff we ended up agreeing upon. As a result, the draft
does not specify a NAT maintenance mechanism and the whole thing ends up
as a configuration issue; note also that nothing prevents a particular
implementation to add its own secret sauce long as the processing
involved (such as pinging) does not bother a standard endpoint.

Pascal

>Sent: Wednesday, July 04, 2007 10:39 AM
>To: Pascal Thubert (pthubert); 'Jari Arkko'
'Basavaraj Patil'
>Subject: RE: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 -