Re: [Monami6] Fwd: I-D ACTION:draft-bagnulo-shim6-mip-00.txt

[Thierry Ernst <[e-mail]>]

> > Sure. But on the agenda we have listed concrete and long standing
> > solutions.  More below.
> Using the SHIM to support multiple hoas seems a very concrete solution
> to me.

It's an approach, not a solution. You draft draft-bagnulo-shim6-mip-00
says:


   SHIM [1] is a host-based mechanism to provide site-multihoming
   support. 

   which refer to:

   [1]  Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach",
        draft-ietf-shim6-l3shim-00 (work in progress), October 2004.

  where it is written:

   This document specifies a particular approach to IPv6 multihoming.
   The approach is based on using a multihoming shim placed between the
   IP endpoint sublayer and the IP routing sublayer, and, at least
   initially, using routable IP locators as the identifiers visible
   above the shim layer.  The approach does not introduce a "stack name"
   type of identifier, instead it ensures that all upper layer protocols
   can operate unmodified in a multihomed setting while still seeing a
   stable IPv6 address.

   This document does not specify the mechanism for authenticating and
   authorizing the "rehoming" - this is specified in the HBA document.

   Nor does it specify the messages used to establish multihoming state.

   The document does not even specify the packet format used for the
   data packets.  Instead it discusses the issue of receive side
   demultiplexing and the different tradeoffs.  The resolution of this
   issue will affect the packet format for the data packets.

So, is this an approach, or a solution ? I think it's one step before
the proper solution. Anyway, you didn't reply my question regarding the
time line.



> 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 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). 

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),

- 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, 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.

Thierry


_______________________________________________
Monami6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/monami6