Re: [netlmm] Consensus call: PMIP6 IPv4 support change

[Sri Gundavelli <[e-mail]>]

Hi Raj,

I'll be fine with mandating UDP encap. But, there was some interest for this
8-byte optimization. We also have the text, flags, other drafts in RFC
editor queue and backed by some prior discussions, so, keeping the same
semantics at this stage will be better, IMO.


Regards
Sri



On 1/19/10 7:45 AM, "[e-mail]" <[e-mail]>
wrote:

> 
> Sri/Vijay,
> 
> What is the downside (other than the 8 byte overhead) of having UDP
> encapsulation for signaling and traffic all the time?
> 
> It simplifies the protocol and avoids the need to verify the presence of
> NATs and flags to switch on/off the encapsulation.
> 
> Why not just have UDP encap as the default.
> 
> -Raj
> 
> 
> On 1/18/10 8:37 PM, "Sri Gundavelli" <[e-mail]> wrote:
> 
>> Hi Vijay,
>> 
>> Yes. The use of UDP encap for NAT detection is just one use-case, that's
>> what I'm saying. I'm not talking about the issue of need for NAT support,
>> keeping that aside, the UDP encap is needed for control. You raised the
>> issue of when we would need it for data path, for firewall traversal or
>> other reasons, if UDP encap is desired, it can be enabled, but it can be
>> turned off when not needed. Hope this clarifies.
>> 
>> 
>> 
>> Regards
>> Sri
>> 
>> 
>> 
>> On 1/18/10 6:27 PM, "Devarapalli, Vijay" <[e-mail]> wrote:
>> 
>>> Sri,
>>> 
>>> Section 4.1.3.3 in version 17 has been removed. Section 4.1.3.3 specified
>>> how the LMA and MAG detect a NAT on the path.
>>> 
>>> Vijay
>>> 
>>> 
>>> On 1/18/10 5:46 PM, "Sri Gundavelli" <[e-mail]> wrote:
>>> 
>>>> Hi Vijay,
>>>> 
>>>> If NAT is not detected and the flags are not set for UDP encap, UDP encap
>>>> is
>>>> not used. Where is the issue ?
>>>> 
>>>> 
>>>> Sri
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 1/18/10 5:38 PM, "Devarapalli, Vijay" <[e-mail]> wrote:
>>>> 
>>>>> Sri,
>>>>> 
>>>>> The proposed change removes the NAT detection capability. So without
>>>>> knowing
>>>>> if there is a NAT on the path, you would end up using UDP encapsulation
>>>>> all
>>>>> the time for the data path.
>>>>> 
>>>>> I don't understand what clarifications you will be adding.
>>>>> 
>>>>> Vijay
>>>>> 
>>>>> 
>>>>> On 1/18/10 5:36 PM, "Sri Gundavelli" <[e-mail]> wrote:
>>>>> 
>>>>>> Hi Vijay,
>>>>>> 
>>>>>> Skipping UDP should be fine for data path, while keeping it for control.
>>>>>> That's fine, will add clarifications as needed.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Regards
>>>>>> Sri
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 1/18/10 4:57 PM, "Devarapalli, Vijay" <[e-mail]> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On 1/18/10 3:48 PM, "Sri Gundavelli" <[e-mail]> wrote:
>>>>>>> 
>>>>>>>> The below change, you are suggesting, we don't use UDP encap for
>>>>>>>> control
>>>>>>>> or
>>>>>>>> data path ?
>>>>>>> 
>>>>>>> For data path. The initial PBU is always sent with UDP encapsulation.
>>>>>>> 
>>>>>>> Vijay
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> Sri
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 1/18/10 10:36 AM, "Devarapalli, Vijay" <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>>> Hi Jonne,
>>>>>>>>> 
>>>>>>>>> I would like to have a NAT detection feature back. I would like
>>>>>>>>> draft-ietf-netlmm-pmip6-ipv4-support to say explicitly that UDP
>>>>>>>>> encapsulation should be used only if NAT is detected. Of course, there
>>>>>>>>> are
>>>>>>>>> flags that might override this behavior, but when the flags are not
>>>>>>>>> set
>>>>>>>>> and
>>>>>>>>> a NAT is not detected, I would like to use IP-in-IP encapsulation.
>>>>>>>>> 
>>>>>>>>> Vijay
>>>>>>>>> 
>>>>>>>>> On 1/15/10 5:41 AM, "Soininen, Jonne (NSN - FI/Espoo)"
>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>>> Hello,
>>>>>>>>>> 
>>>>>>>>>> This is an "official" consensus call on the proposed changes
>>>>>>>>>> documented
>>>>>>>>>> at
>>>>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 
http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-18a-p>>>>
>
>> 
>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> a
>>>>>>>>>> si-jikv3.txt.
>>>>>>>>>> 
>>>>>>>>>> Please, indicate if if you are in favor, or against the proposed
>>>>>>>>>> change,
>>>>>>>>>> and
>>>>>>>>>> the reason for your position.
>>>>>>>>>> 
>>>>>>>>>> Consensus call: PMIP6 IPv4 support change
>>>>>>>>>> Start: Now
>>>>>>>>>> End: January 29th, 2009 EOB Pacific time.
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> 
>>>>>>>>>> Jonne.
>>>>>>>>>> --
>>>>>>>>>> Jonne Soininen
>>>>>>>>>> Nokia Siemens Networks
>>>>>>>>>> 
>>>>>>>>>> Tel: [phone]
>>>>>>>>>> E-mail: [e-mail]
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> netlmm mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> netlmm mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>> 
>>>>>> 
>>>> 
>> 
>> _______________________________________________
>> netlmm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netlmm
>