Hi Thierry, As I've just written in my email to Henrik, this was a discussion point I was providing to discuss the feasibility of it. But, if it is something people feel is viable, it will be a slightly different approach from any of the proposed approaches thus far, yes.
Vidya > -----Original Message----- > From: Thierry Ernst [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 15, 2007 4:20 AM > To: Narayanan, Vidya > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [Int-area] Lifting up a filter discussion from Monami6 > > > So, you are proposing a 4th solution if I got you right ? > > Thierry. > > > On Wed, 14 Feb 2007 14:20:48 -0800 > "Narayanan, Vidya" <[EMAIL PROTECTED]> wrote: > > > > >I would be sympathetic to developing something generic that > works for > >multiple protocols instead of just Mobile IP, while also keeping in > >mind the issue of mobility and latency concerns associated > with that. > >One thing to take into account is that this exchange is not > necessarily > >a one-time exchange and policies and filters may change over time, > >based on the current connection capabilities of an end host. In such > >cases, some of this signaling may potentially be bound to > handoffs and > >in the context of Mobile IP or MOBIKE-like protocols, if this means > >separate signaling exchanges before the flow changes can happen, it > >could be less than useful. > > > >I had briefly discussed this with Dave Thaler in San Diego > and we had > >talked about defining the flow information in a generic > format, perhaps > >as an IPv6 extension header or as a Destination Option. If such an > >approach were to be taken, this information could then be carried in > >any protocol, which would get rid of additional signaling > and latency > >concerns associated with it. So, from this point of view, a > couple of > >different things would need to happen - an independent specification > >needs to define such an extension header or destination > option and the > >fields that go into it; a different specification would then > describe > >how this is carried in a given protocol (say, Mobile IP) and how the > >information is secured within that context. > > > >Thoughts on something like this? > > > >Vidya > > > >> -----Original Message----- > >> From: Jari Arkko [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, February 14, 2007 5:00 AM > >> To: Internet Area > >> Cc: [EMAIL PROTECTED] > >> Subject: [Int-area] Lifting up a filter discussion from Monami6 > >> > >> > >> I would like to lift up one issue from the Monami6 WG to a more > >> general discussion. Monami6 is developing an extension to > Mobile IPv6 > >> / Nemo so that a mobile node could register its presence > in multiple > >> locations simultaneously. > >> One of things that they expect to be able to do is to control what > >> traffic goes to what care-of address; this flow to this > address, and > >> the other flow to that other address. Mobile nodes can obviously > >> decide by themselves what outgoing interface to use. > >> However, in order for a home agent to deal with return traffic > >> properly, the mobile node has to tell it what policy to employ. > >> > >> The working group has debated between a number of different > >> approaches for doing this. In one approach, draft-soliman- > >> monami6-flow-binding the mobile node adds a filter to a Mobile > >> IPv6 Binding Update to tell what traffic should use this binding. > >> Another approach, draft-larsson-monami6-filter-rules, > >> decouples the policy exchange from the mobility protocol. The > >> policies are exchanged at a different time (typically > >> earlier) and carried by a different protocol (in this case > over UDP). > >> Yet another draft, draft-mitsuya-monami6-flow-distribution-policy > >> also separates the mobility protocol and policy transfer, > and carries > >> the policies in HTTP. > >> > >> Monami6 should of course decide how they want to design this. > >> But this may be an interesting debate from a more generic point of > >> view. Do we have input for them? For instance, are there needs in > >> HIP/Shim6/Mobike space for similar functionality? Should > the designs > >> be tailored for each of these situations? Is there some > advantage or > >> disadvantage in looking at a generic solution? > >> Would a generic solution be doable? > >> > >> Without going into too much detail about the specific proposals it > >> seems that there are actually a number of different topics here: > >> - carrier protocol choice > >> - policy container format > >> - timing of the policy exchange > >> - securing the transfer > >> - etc > >> > >> Thoughts? > >> > >> Jari > >> > >> _______________________________________________ > >> Int-area mailing list > >> [email protected] > >> https://www1.ietf.org/mailman/listinfo/int-area > >> > > > > > -- > Thierry ERNST, PhD > INRIA Rocquencourt France Project-Team IMARA / JRU LARA > http://www.lara.prd.fr +33 1 39 63 59 30 (office) > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
