Subject: Re: bulk registration (was Re: [Monami6] Changes needed to MCoA draft?

From: Gábor Fekete <[email-masked]>
Date: Tue, 11 Apr 2006 17:50:02 +0300

Hi Marcelo and Tero and list,

On Tuesday 11 April 2006 16:06, marcelo bagnulo braun wrote:
> ...
> 
> > I don't think it is a problem to have two separate drafts (they are
> > only drafts anyway). In that case, the basic MCoA draft should drop all
> > the "bulk registration" related text.
> >
> 
> but what is the point in having two draft?

to keep everyone happy :) well, i am not thinking about drafts written in
stone. ok, i don't really know how it goes, but my idea is to create drafts
and then just pick the one that's the best; or mix and match and create
the One True Draft. and if it means there won't be an MCOA WG draft by "next week"
then be it. yes, actually, is there any hard deadline?

> 
> my point is that we need to figure out how this bulk registration stuff 
> fits in the mcoa support anyway in order to do it right so, i guess we 
> can do it once and for all
> 
> > But I would suggest someone taking the MCoA draft and rewrite it with
> > bulk in mind from scratch and just see how it shapes up. I don't think
> > it would hurt. E.g. Martti Kuparinen had quite nice ideas...
> >
> 
> yes, this is the approach that i would suggest, try to figure out how a 
> mechanism to support mcoa registration and bulk registration would look 
> like
> 
> ...
>
> > In this case I see one complication in the error handling, e.g.
> > "What if a bulk-mcoa MN talks to a non-bulk-mcoa implementer CN?"
> >
> 
> this is just one of the issues that may appear....
> i mean since day one we will have multiple vrsions of the mcoa 
> registration support.... i don't think this is the best approach

there would not be multiple versions, i think people here are smarter than
that ;) but yes, i get your point.

> >
> > IMO, bulk-reg reduces signaling overhead. The problem is currently
> > there are no services (at least I am not aware) deployed using mipv6
> > and not many ipv6 sites. At first glance Bulk-reg is good on e.g. boot 
> > up
> > and if you have multiple CoAs on a single interface.
> 
> Do you think that bulk registration will only be usefull for multiple 
> coas in a single interface? why is that?

i did not say "only", i said "e.g." on purpose :)
but ok. let's take a MN with 3 interfaces (I think the one-iface
scenario is obvious, we need bulk-reg if we have multi-coa on that iface).
I assume that one BU can tell the story of only one HoA, is it right? 
then, suppose the MN is booted and already has multi-coa bindings
with CN for the 3 ifaces. and also suppose that there is one CoA per
iface. So CN's bcache has an entry like:

     +- CoA1 - BID1
     | 
HoA -+- CoA2 - BID2
     |
     +- CoA3 - BID3    

You need to send bulk-reg to CN if you want to change multiple BIDs at CN, but
otherwise you are fine with non-bulk. Now, each CoA belongs to a different
iface. Therefore, the event that causes you to send a bulk-reg to CN is
actually a combination of events happening "at the same time" w.r.t different
interfaces. This assumes an MN implementation that is intelligent enough
to aggregate events and send bulk-reg whenever possible.
so, yes, in this scenario a MN may use bulk-reg if it is smart enough.
errrr... well, so my point is, yes, in this scenario bulk-reg is a nice
feature but may be used by less implementations than the boot-up and
multi-prefix cases.

> 
> >  But in the latter case
> > will it be common in the future to have ipv6 subnets with multiple 
> > network
> > prefixes?
> 
> well, multihomed networks are expected to have multiple prefixes (at 
> least in several cases) so i guess this may be pretty common (just 
> guessing of course)

ok. i guess there may be many multihomed sites...

> 
> >  So for me it's a bit like planning blind and whether we need it
> > or not may not be that clear at this point. Or am I saying bull?
> >
> 
> > I say, just create a draft for bulk (either rewrite mcoa or create a
> > separate draft and drop bulk-reg from mcoa) and
> > see if the result is over-complicated or simple and clean.
> >
> 
> fully agree, but this is needed before taking on the work in the 
> current mcoa draft in the wg, so that we can figure out if a mcoa 
> mechanism that supports bulk registration is compatible or not with the 
> current mcoa draft... agree?

yes. so, again. I suggest to
1) make a non-bulk mcoa and make an add-on bulk-reg draft.
   I wonder if Ryuji already started this work.

and

2) make a bulk-reg mcoa draft from scratch?

That's all. And yes, maybe Tero (and others) already has ideas about
the add-on bulk-reg draft that is why he's suggesting the 2-draft scenario.
Or am I wrong?

I think that Ryuji wants to keep the mcoa draft as simple as possible and
he may be afraid that a full-featured bulk-reg text would overcomplicate it.
If it's not the case then neither I see point in having a non-bulk and
a bulk drafts parallel. And probably there is a WG deadline for the MCoA
draft...

But i may say no more since I just blabla and not writing the drafts :)

thanks,
gabor

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

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 11 Apr 2006 17:14:22 +0200

Gabor,

>then be it. yes, actually, is there any hard deadline?
Yes there is (from the charter at 
http://ietf.org/html.charters/monami6-charter.html) :

Jun 2005  Submit Multiple CoA Registration to IESG

Regards,

Nicolas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 12 Apr 2006 11:47:38 +0300

> Jun 2005  Submit Multiple CoA Registration to IESG

you are right, this is what the web page states but this is really 
strange... the monami6 working group was formed in the 30 september of 
2005, which makes me wonder how would it be possible to be on schedule 
and submit documents to the IESG  3 months before the group was ever 
created....

so i don't think this is hard deadline, since it has always been 
impossible to make it....

i really think we need to update the charter to include more realistic 
dates on it, like ones that do not require traveling in time in order 
to be able to accomplish them... :-)