Re: [MEXT] GRE support in DSMIPv6 - AD review

[Hesham Soliman <[e-mail]>]

> 
> The issue would be that this spec needs to understand the payload
> qualifier, else we cant add themm later.

=> It's not true though. You can add the exact same thing that we have in
the draft now but specify it in a more complete manner and it will be
backward compatible and interoperable. The negotiation bit in the BU would
have to be included in the new draft of course.

Hesham

Its the same DSMIP UDP flow,
> one with the flows carried natively and the other with some format
> that we will define some where else. As pointed out earlier and
> also as a matter convention set by RFC-3519, we cant carry payloads
> with out a proper header. All protocols have always provided some
> form of thin header, which identifies the type of payload it carries.
> Ignoring the GRE discussion, we need this TLV header even for that
> reason.
> 
> Sri
> 
> On Mon, 19 Jan 2009, Behcet Sarikaya wrote:
> 
>> Hi Sri,
>>   You are right, it exists in MIP4. For some reason it doesn't in MIP6. GRE
>> key draft proposes to use it mainly for IPv4 traffic.
>>   My suggestion is to move TLV text to the netlmm GRE key draft. This way we
>> have everything related to GRE in one document. As you said that document
>> does not disallow using it in (DS)-MIPv6. So a win-win case .
> 
> 
> 
>> 
>> Regards,
>> 
>> Behcet
>> 
>> 
>> 
>> 
>> ________________________________
>> From: Sri Gundavelli <[e-mail]>
>> To: Basavaraj Patil <[e-mail]>
>> Cc: Behcet Sarikaya <[e-mail]>; Jari Arkko <[e-mail]>;
>> [e-mail]; Pasi Eronen <[e-mail]>
>> Sent: Monday, January 19, 2009 2:06:33 PM
>> Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review
>> 
>> Ok. Thanks Raj.
>> 
>> However we do, fixing it in this doc as planned initially,
>> in a new doc, the mode should be available to both network-based
>> and client-based mobility, that will keep the initally agreed upon
>> consensus as reflected when the doc was sent to IESG by the WG. We
>> still need to adress the comment on the lack of text and IMHO this
>> doc is the right place as the mode is common to all.
>> 
>> Hope this one last comment gets resolved the right way.
>> 
>> Regards
>> Sri
>> 
>> 
>> On Mon, 19 Jan 2009, Basavaraj Patil wrote:
>> 
>>> 
>>> Sri,
>>> 
>>> For the resolution of the IESG comments regarding the TLV header, I have
>>> said that this spec should get rid of it and if someone feels the need for
>>> it to be specified, they can do so (potential docs suggested being the IPv4
>>> support I-D or the GRE Keys I-D in Netlmm WG).
>>> 
>>> My comment was based on the reopening of the discussion regarding the need
>>> for GRE encapsulation in the context of DSMIP6. I agree that nothing has
>>> changed since we had this discussion a while ago and as you can tell neither
>>> has my opinion regarding the need for GRE for host based mobility.
>>> But I am fine with whatever is deemed as the consensus regarding the TLV
>>> header and/or GRE encapsulation support in the DSMIP6 I-D.
>>> 
>>> -Raj
>>> 
>>> 
>>> On 1/19/09 1:01 PM, "Sri Gundavelli" <[e-mail]> wrote:
>>> 
>>>> Raj,
>>>> 
>>>> We went over all this list year back. You asked the same question,
>>>> you got the same answers. There are no new arguments. If you want
>>>> to ignore the use of GRE key in NEMO use, for marking different MNP
>>>> flows for differential treatment on the HA, or the point of carrying
>>>> legacy payload traffic, or about a single integrated HA/LMA serving
>>>> mobile nodes and leveraging a common encap mode, you may so, but the
>>>> fact reamins. Its useful in PMIP, it may be useful in NEMO, or may not
>>>> be so useful in client-MIP, fine, lets not apply restrictions.  If we
>>>> have a home agent that can perform GRE switching in the hardware, its
>>>> a good reason for me to leverage for all mobile flows and not build one
>>>> more mode.
>>>> 
>>>> We really should not be re-opening converged cases. There is a AD
>>>> comment on lack of specification on the tunneling mode, we can
>>>> easily fix that, rather dug open the whole mountain. Hesham spent
>>>> lots of time on adding all the TLV and the related support, we
>>>> dont have to waste all that, if there is some thing minor missing.
>>>> 
>>>> Regards
>>>> Sri
>>>> 
>>>> 
>>>> On Mon, 19 Jan 2009, Basavaraj Patil wrote:
>>>> 
>>>>> 
>>>>> I still fail to really understand why GRE encapsulation is needed for host
>>>>> based mobility (DSMIP6).
>>>>> The only argument below is that it provides "richer semantics than
>>>>> IPv6-in-IPv6". Can you provide an explicit example of how the richer
>>>>> semantics are useful vs the IP-in-IP encapsulation for DSMIP6?
>>>>> 
>>>>> Cheers,
>>>>> -Raj
>>>>> 
>>>>> 
>>>>> On 1/19/09 12:09 PM, "Sri Gundavelli" <[e-mail]> wrote:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Fri, 16 Jan 2009, Behcet Sarikaya wrote:
>>>>>> 
>>>>>>> [behcet] I couldn't understand why MN would need to support GRE. Can
>>>>>>> someone
>>>>>>> explain the use case?
>>>>>>>  
>>>>>> 
>>>>>> This issue was discussed at length. Many reasons were cited as why the
>>>>>> GRE encapsulation mode may be needed in client-based mobility and why
>>>>>> it should not be restricted to network elements alone.
>>>>>> 
>>>>>> The LMA element in Proxy Mobile IPv6 is a feature extension to the
>>>>>> Mobile IPv6 home agent. They have a strong relation. If some one
>>>>>> implements home agent function, implements the data plane with all
>>>>>> the hardware support for GRE and it cant be leveraged when supporting
>>>>>> client-based mobile nodes ? Its the same home agent that serves both
>>>>>> types of nodes.
>>>>>> 
>>>>>> The options that we are standardizing NETLMM or MEXT, each should not
>>>>>> take a different path. Its not that we have one revocation option for
>>>>>> PMIP, one for NEMO and the other for MIP6. Keeping them together will
>>>>>> save implementors to leverage all these features and resources across.
>>>>>> 
>>>>>> GRE is another enapsulation mode, it exists with much richer semantics
>>>>>> than IPv6-in-IPv6. The ability to carry non IP traffic, I'm not saying
>>>>>> I support this for carrying IPX/AT traffic, but the point that its a
>>>>>> useful encapsation mode that exists in MIP4 and cant be ignored for
>>>>>> good reasons.
>>>>>> 
>>>>>> Sri
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Thanks,
>>>>>>>  
>>>>>>> Behcet
>>>>>>> 
>>>>>>> 
>>>>>>>> Hi Pasi, Hesham,
>>>>>>>> 
>>>>>>>> The TLV header was specified in the DS-MIPv6 document after rather a
>>>>>>>> long and acrimonious debate on the former MIP6 mailing list. There were
>>>>>>>> atleast two consensus calls that were run at that time.
>>>>>>> 
>>>>>>> => I don't realy want to get into that, we all know there was no
>>>>>>> concensus
>>>>>>> and we had to teleconference to come up with the existing method
>>>>>>> 
>>>>>>> Anytime you have
>>>>>>>> a UDP header with IPv4/IPv6/GRE header following it, you need the TLV
>>>>>>>> header.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> _______________________________________________
>>>>>> MEXT mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>> 
>>>>> 
>>> 
>>> 
>> 
>> 
>> 
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext


_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext