[Monami6] What are the mobility issues vs generic issues ?

I renamed this thread from 
[Fwd: I-D ACTION:draft-bagnulo-shim6-mip-00.txt]

> >> and i am not sure what do you mean by long standing... in which way
> >> the other solutions being presented are long standing?
> >
> > Solutions that exist for a long time and have been implemented, and 
> > even
> > tested in real-life trials. I think Shim6 is still a little bit
> > behind this.
> >
> 
> i feel we are going way too fine grained here for a bof
> presentation... are you telling that the all the drafts that are being
> presented have been tested in real life? Do you have any references
> (pointers) to that real life trails of those solutions?
> besides what do you consider to be long time? 1 year, 2 years? and
> this long time in which status...? i mean SHIM has been a wg draft for
> about 6 months now, and there is a whole wg working in its design, can
> you say that any similar amount of effort is being invested in any of
> the other solutions?

These solutions have been introduced to the IETF for the 1st time years
ago. Multi6 didn't even existed, unless I'm mistaken.

I will not speak about HA filtering and the Nomad solutions because I'm
not involved, so other folks will give details if you want, but
regarding Multiple CoA registration, the draft is implemented under
Shisa, and undergoing under Linux, and has been tested and demonstrated
during the ITS World Congress at Nagoya last year (on a MR with
multiple interfaces)

> But i mean, i don't see how this is meaningful for a bof
> presentation... As i said, imho in a bof the problem space is to be
> explored and imho the shim could contribute with a significant part to
> solve the problem in hand...

The problem space is explored in the pb statements drafts, those draft
will need to be improved, but I don't think the BOF can be devoted to
improve the drafts. The BOF should be devoted to set up the WG, and one
of the miltestone of the WG is to publish such a PB Statement draft as a
WG document. I count on you to improve this WG PB Statement draft if the
WG is set up. If the WG is not set up, then, I don't see any venue for
such work going on. So, I think that if you think this pb deserves
consideration, the best is to push for this WG to be created with an
acceptable set of milestones including this PB statement document. 

> >>>> I mean, in the included agenda there is a section where solutions
> >>> will> be presented:
> >>>> So, my question to you is why do you think that it is ok to
> >present>>> these proposed solutions and not the shim approach?
> >>>>
> >>>> IMHO, it is ok to explore the solution space in a bof and the
> >shim>>> should be presented, just as any of the other approaches....
> >>>
> >>> Well, 1st Shim6 is not a solution but an approach, am I right on
> >>> this ?
> >>>
> >>
> >> not sure what would be the difference, but in the draft presented
> >you> can find a proposal to support multiple HoAs in MIP
> >
> > Ah, OK, then I may see where we don't understand each other.  The
> > support of multiple HoAs is not a MIP-specific issue (please refer
> > to draft-montavont-mobileip-multihoming-pb-statement).
> 
> 
> I copy your sentence above: The support of multiple HoAs is not a 
> MIP-specific issue
> 
> HoAs are defined by the MIP spec, right?
> so how come that the support of multiple Hoas is not MIP specific???
> 
> sorry but, it seems a contradiction to me

Where is the contradiction ? The HoA and the CoAs are mobility terms,
there have a meaningful significance only when a CoA is bound to the
HoA, i.e. when the MN wants to maintain his sessions when located on
another link than the home link. 

When located on the home link, you can call it a HoA if you want, but
this is just a global address right, as the MN doesn't send BUs, etc.

To me, having multiple HoA just mean having multiple global addresses,
which is a multihoming configuration which is bring some issues, but not
specific to mobility.

On the other hand, having multiple CoAs, which is also a mutihoming
configuration, brings a mip-specific issue when the MN wants to register
more than one CoA with the same HoA. So, the mip-specific issue is
called"Binding Multiple CoAs to a given HoA".

Marcelo, would you react according to
draft-montavont-mobileip-multihoming-pb-statement where there is
no "multiple HoA" issue ? There is some text about this
configuration under the "Path Selection" issue, which is not ranged
under the MIP issue.

So, if there is a mobility specific issues that we have failed to
discuss in the draft, then yes, we would like to discuss this point in
order to improve the draft.

I'm not sure my explanation is satisfactory, but I guess you get
my point.

> > So, the purpose of Monami6 is:
> >
> > - Develop Standard Track specifications for the mobility-specific 
> > issues
> > that work both for mobile hosts operating Mobile IPv6 and mobile 
> > routers
> > operating NEMO Basic Support and their variant (FMIPv6, HMIPv6,
> > etc),
> >
> 
> right, supporting multiple HoAs seems to be a core MIP specific issue

See my earlier comment.

> > - Seek for help or push the other WGs to standardize solutions not
> > specific to mobility.
> >
> > So, Shim6 is a valid solution for an issue which should potentialy
> > be solved in another WG. The charter basically try to say that
> > Monami6 will
> > seek help and place requirements on other WGs for such issues. It
> > may eventualy solve the issue by itself if not other WG is chartered
> > to do it.
> >
> >>> Second, the other drafts are clearly extensions to MIP, right ?
> >>>
> >>> MIP6 and NEMO BS are standards, combining some of the features
> >like>> MCoA
> >>> into a standard can give us a RFC by early 2006. What's the time
> >>> line for Shmi6 ? I don't know.
> >>>
> >>> If you could explain on the ML what Shim6 can bring by early 2006,
> >>> this would help.
> >>>
> >
> >> But the point is that supporting multiple HoAs will imply
> >> modifications in the CN (i.e. all the hosts in the internet)
> >
> > Agree.
> >
> >> So, any solution for this problem will take some time to deploy.
> >
> > Agree.
> >
> >> The point being made is that the shim will be deployed for
> >supporting> site multihoming, so if the shim can also provide support
> >to mip> multihoming, the deployment effort would be greatly reduced.
> >Not> exploring the possibility of using the shim and finding out what
> >can> it provides may imply important additional deployment cost for
> >> supporting MIP multihoming
> >
> > Agree with you all the way long.
> >
> >> So, i see it exactly the opposite way, shim would provide a faster
> >> track to deploy modifications that involve CNs, since it would be
> >more> reasons to deploy it than (i.e. site multihoming)
> >
> > The point is that a this moment we have no intention to solve the
> > multiple HoA probem,
> 
> In the charter it is clearly stated that:
> 
> Basically, mobile nodes with multiple interfaces (likely bound to
> distinct HAs) would end up into having multiple home addresses and
>                                         ^^^^^^^^^^^^^^^^^^^^^^^

So what ? It is discussed as a configuration, not as an  issue that the
WG will have to deal with. 

> /or care-of addresses. Such multihoming configuration results in a
> multitude of paths and a number associated issues: multiple path
> establishment, path selection and path redirection as multiple
> pairs of home addresses and care-of addresses would have to be
> maintained between the mobile node and its home agent(s). Some of
> the issues are very specific to mobility and generally apply to
> both mobile hosts operating Mobile IPv6 and mobile routers
> operating NEMO Basic Support. It is however expected that
> Mobile IPv6 and NEMO Basic Support would be affected by small
> straight forward changes (e.g. multiple CoAs registration),
> whereas additional non-MIP-specific mechanisms may be needed
> to fully benefit from the multihoming configuration.
> 
> Also in the problem statement draft the case of multiple HoAs is 
> clearly considered

You speak about configuration or issues ? So far, we have not written
anywhere that we want to solve the issues that are related with
having multiple HoAs (i.e. having multilple global addresses, see my
earlier comment).

> So, why do say that the multiple HoAs case is out of the scope of the 
> BoF?

Either you don't understand the scope of Monami6 for some reasons
based on past assumptions or different perceptions, or either I didn't
explain things correctly.

> I mean, IMHO MIPv6 multihoming is much more than just registering 
> multiple CoAs, as it is described in the charter that i quoted above 
> and it is explained in the problem statement draft... are you
> proposing to make a whole WG to define how to register multiple CoAs?
> 
> I guess that the point of a MIP multihoming wg would be to solve the 
> mip multihoming problem, in all its complexity and trying to deal with
> most of the problems identifed in the problem statement.

I think I wrote the following several times already: the pb statement is
trying to be exhaustive into LISTING the issues that are coming with
multihoming nodes operating MIP6 or NEMO BS (i.e. when they have
multiple HoAs or CoAs.). The PB statement is expected to be one of the
deliverable of the WG. The WG would work on the very MIP and NEMO
specific issues (such as registering multiple CoAs with a HoA), and, for
the other issues, it will seek help or place requirements with other
WGs. So, I take the issues coming with Multiple CoAs as not failing into
the issues the Monami6 WG wants to solve, but as issues that would be
solve somewhere (and with which Monami6 should cooperate).

> >  so it's perfect if Shim6 is doing is, in which case
> > Monami6 would have to guarentee the interaction, which is exactly
> > what the charter is attempting to say.
> >
> > So, I think we agree on the far-end implications, but possibly not
> > on the meaning of the monami6 wording.
> >
> 
> perhaps we don't agree on the goal of a wg for dealing with mip 
> multihoming.

Yes, it seems we don't. 

> we seem to agree with what the problem is, since i guess we both 
> somehow agree with the problem statement draft, but you seem not to be
> interested in solving the whole problem described there, but just 
> registering multiple CoAs, is this correct?

Not just "registering multiple CoAs", but also the other mobility
specific issues.  In draft montavont we have a set of issues. If you
think that there are additional mobility issues, please comment on
another thread, this will help to understand your point. 

Thierry

_______________________________________________
Monami6 mailing list
Monami6@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/monami6