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

From: Hiroshi Ohta <[email-masked]>
Date: Wed, 12 Dec 2007 15:36:04 +0900

Working group,

As we agreed in the mboned session during IETF-70 in Vancouver, we start
the WGLC for comments on <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>
with this note.  The draft can be found on

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

Please review the document carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this
document is ready to go to the IESG.

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.

Thank you.
Hiroshi and Marshall

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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 12 Dec 2007 13:34:23 -0800

I do not support for the draft to move forward in its current form. ...
but read on ;-))

1. Use SSM

   When applied to the global internet, it proliferates the choice of ASM multicast
   that in my understanding has been recognized to be no long term IETF preferred 
   choice (based on the status of MSDP necessary to support it). All the applications
   for global address space that i have seen would better be served with SSM too
   anyhow, so i i will claim that i have not seen sufficient justification
   (requirements) for what the draft claims to provide a solution for.

2. Do not allocate global addresses for private scoped address use.

   The overwhelming mayority of addressing AFAIK is requested for content distribution
   in private peerings, never to be handed to the global Internet. Like all the
   market data or TV providers that i had the unpleasant experience trying to keep
   as happy customers while still explaining why i hate the allocation of of more
   Internet scope ASM addresses ;-)
   
   I would thus propose to redesignate this draft not for allocation of
   addresses for the global I, but for an IP multicast version of ULAs like
   existng for IPv6 in unicast (Unique Local Address, rfc4193), aka: define
   that this additional ASM address space is an extension of administrative
   scoped multicast addresses that just are globally unique, but that will not
   be routed across the bit I.
   
   This approach will effecively inhibit the problem of proliferating/extending
   the use of MSDP across the internet to cover these addresses. As well as allowing
   us to be more lenient as to how these addresses are being used (like using SM when
   it should be SSM). After all, it is the unique nature of the multi-AS transit 
   Internet, it's size and security concerns that brings in a lot of the reasons of
   trying to get rid of both ASM and the standard model for it (PIM-SM+MSDP).
   But the IETF should not police the freedom to use a wider variety of multicast 
   practices within the privacy of one own's enterprise or provider/subscriber
   extranet, so ULA seems to be the logical choice here ;-)) 

   And yes, this will leave the research community that as far as i see it the
   primary community using the actual global I for ASM multicast out in the
   cold & dark night of really following the targeted IETF directions (SSM, IPv6), but
   i hope they are actually paid to do that anyhow (or should be proud in trying to do
   this at least ;-))

3. Consider hard coding of address issue

   Unless we come up with a better way for lame application developers, we
   will see these addresses hardcoded into applications purely for ease of service
   discovery. I would like to avoid that as much as possible, because within
   the context of this draft that constitutes an extreme abuse (you never own
   unicast adress space forever, so you can't hardcode anything derived from it
   into applications).

   For this reason, i would strongly suggest NOT TO CONSIDER PERMANENT ASSIGNMENT
   right now for these addresses (unless eg: 4. hapens).

4. Whether or not proposals such as the one from Beau will have an impact on
   getting rid of problem 3. is to be seen. In my cynic view, anything but a
   hard coded address will be too difficult to the lame developers who currently
   claim to have a problem *sigh*.

   In any case, it might be useful to consider an actual IANA policy to
   specifically assign such to-be-hard-burned addresses, also from this ULA
   space (as none of these resource discovery mechanisms will or should run
   across the global internet). One cOuld easily use some subrange of
   <ULAbyte>.[224...255].X.Y. As we obviously can only assign [1...223]
   with a unicast allocation derived scheme. And by making an IANA
   assignment with somemandatory informational RFC to specify what application/protocol
   is used there we will at least get documentation for such hard coded addresses,
   and by mean of being ULA, we can relax the architectural constraints

   (like hard coding address discovery is not a good thing ;-) - no, it'snot,
    but in the privacy of one own's home,oops: enterprise, the IETF can be more
    lenient and succump to common practice.... even if there is something wrong with
    it ;-).

Summary: rewrite draft to claim address assignment for an IPv4 multicast
grop ULA space. get another draft done to explain how to assign targeted hard-coded
addresses from the same space (<ula>.224...239) that would maximize
the amount of mandatory public documentation produced for such address usage.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 12 Dec 2007 13:34:23 -0800

1. Use SSM

   

Cheers
    Toerless