[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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" <sgundave at cisco.com> 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
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext



_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext