Subject: Re: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jan 2008 07:47:35 +0200 (EET)

On Fri, 14 Dec 2007, Marshall Eubanks wrote:
>> This document proposes an experimental method of statically
>> allocating multicast address ranges with global scope.  As described
>> in section Section 4, this experiment will last for a period of one
>> year, but may be extended.
>> 
>> I don't see why it can't be permanent. Is this document going to be
>> only experimental? Anyway, I hope we will get the opportunity to
>> extend it later then,
>
> I too don't see why it should be experimental at this date. If there
> is consensus on this point, the draft can be revised without
> requiring another WGLC.

I agree that if this was an experiment, especially an experiment 
running only for a year (one year from document approval?  from RFC 
publication?  what happens after that?), this allocation method 
doesn't seem very useful.

The experimental part should be removed or the timescale changed to 3 
or 5 years with better description of "then what?".

I support the draft going forward.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jan 2008 07:47:35 +0200 (EET)

---

From: Peter Koch <[email-masked]>
Date: Tue, 29 Jan 2008 19:37:38 +0100

On Wed, Dec 12, 2007 at 03:36:04PM +0900, Hiroshi Ohta wrote:

> http://www.ietf.org/internet-drafts/draft-ietf-mboned-ipv4-uni-based-mcast-04.txt

> This Last Call will end on January 11, 2008 at 1400 EST (UTC/GMT-4).  We
> set the WGLC period longer than usual considering we have holiday season
> during this WGLC period.

apologies for the late reply.  I have no strong preference one way or another,
but I think there's text in the document that could benefit from external
review from the RIR/LIR community maybe even prior to IETF Last Call.

>   Compared to GLOP, an AS will receive more address space via this
>   mechanism if it has more than a /16 for unicast space.  An AS will
>   receive less address space than it does from GLOP if it has less than
>   a /16.
>
>   The owner of a UBM address can be determined by taking the multicast
>   address, shifting it left by 8 bits, and identifying the owner of the
>   address space covering the resulting unicast address.

First, unicast addresses are distributed through the IANA->RIR[->NIR]->LIR
channel, so a particular /24 may end up being allocated (to an LIR)
but not assigned to a single end user.  Since address policies are
developed in the five RIR regions, is this something the bodies concerned
need to address?  Is the multicast group address for the LIR to
assign/distribute?

The term "owner of address space" is likely incompatible with current
assignment policy documents (at least for the RIPE region, it isn't used,
if not avoided).

Is there any intention to support DNS reverse mapping for the /8-to-be?
If the decision is up to the RIRs, the document might want to explicitly
defer this.

Since everybody "owns" 10/8 and the other RFC 1918 addresses, what happens
to these and all the other parts of the multicast /8, e.g. XX.127/16
and XX.224/12?

-Peter

---

From: Peter Koch <[email-masked]>
Date: Tue, 29 Jan 2008 19:37:38 +0100

-Peter

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Jan 2008 20:56:14 +0200 (EET)

I was wondering whether the thread would ever end and chairs could 
figure out what are the next steps, but it's always nice to see a good 
review after mostly offtopic discussion.

My take..

> review from the RIR/LIR community maybe even prior to IETF Last Call.

Good point, I have no strong feelings about the timing.  Document 
requires a revision in any case (the experiment or at least the length 
of it).  If a rev could be done before the I-D cutoffs close, RIR/LIR 
community could review it during IETF LC.  If not, RIR/LIR community 
could review a non-final suggestion earlier.

> need to address?  Is the multicast group address for the LIR to

Maybe a clarification is needed.  The intent is that this document 
provides a "mapping function" that each network can employ on their 
own, just like they can employ for GLOP address space.  No assignment 
or allocation action by LIR or RIR is needed.

> assignment policy documents (at least for the RIPE region, it isn't used,

Good point, this could probably be fixed based on specific comments 
from the regions.

> If the decision is up to the RIRs, the document might want to explicitly

My personal belief is "no", because I don't see this compatible with 
the "mapping function" nature of address space and the overhead caused 
by reverse delegation in this kind of context.

> to these and all the other parts of the multicast /8, e.g. XX.127/16

Maybe some warning here would be useful.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Jan 2008 20:56:14 +0200 (EET)

My take..