Subject: Re: New draft on embedding the RP address in IPv6 multicast address

From: Brian Haberman <[email-masked]>
Date: Thu, 10 Oct 2002 13:29:59 -0400

Marshall Eubanks wrote:
> Yes, I think so, this requires interdomain flooding, just like 
> interdomain MSDP in IPv4.

Actually, I don't think it does.  See comments below.

> 
> However, you might be able to make ASM "SSM like" in that, if you
> find the group address by some means out of band, you can join to the RP 
> and either send or receive.

This is actually what is expected to happen.  The steps look like:

      1. A receiver finds out a group address from some means
         (e.g. SDR or a web page)
      2. The receiver issues an MLD Report Joining the group
      3. The receiver's DR will initiate the PIM Join process
      4. The Join message flows up to the receivers RP
      5. The RP recognizes the embedded RP format and extracts
         the owning RP address
      6. The receiver's RP issues an SPT join to the owning RP
         and creates forwarding state

One possible optimization is that the receiver's DR could issue
the SPT to the owning RP.

The sender side has two cases.

      1. A sender in the owning domain.  Nothing should be different
         here.

      2. A sender in a foreign domain.  This is the case that I
         have to do some work on.  In order for a receiver in
         another domain to know about this sender, information will
         have to flow to the owning RP.

> 
> It is also not clear to me how this would work in, say, a 
> teleconference. Doesn't it limit the group to only _one_ RP? What 
> functionality does it give that either SSM or MSDP doesn't ?

One big advantage is the removal of inter-domain MSDP state.  And
the use of one RP is a downside of this approach.

Brian

---

From: "Mike O'Connor" <[email-masked]>
Date: Thu, 10 Oct 2002 08:47:18 -0700

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

If all source active advertisements are carried in PIM packets won't we
need to flood and prune our local source PIM packets to all or our
interdomain neighbors? Would this draft accommodate PIM sparse mode?

-Mike

--
Mike O'Connor,                  E-mail: [email-masked]
Network Engineer                Energy Sciences Network (ESnet)
East coast: +1 631 344-7410     West coast: +1 510 486-7421
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Thursday, October 10, 2002 8:20 AM
To: Marshall Eubanks
Cc: [email-masked]; [email-masked]; Brian
Haberman
Subject: Re: New draft on embedding the RP address in IPv6 multicast
address

On Thu, 10 Oct 2002, Marshall Eubanks wrote:
> On Thu, 10 Oct 2002 14:21:44 +0300 (EEST)
>  Pekka Savola <[email-masked]> wrote:
> > Hello,
> > 
> 
> Dear Pekka;
> 
>    A quick question about Section 4 :
> 
>   o "plen" MUST NOT be 0 (ie. not SSM)
> 
>      o "plen" MUST NOT be greater than 96
> 
>    The address of the RP can be obtained from a multicast address by
>    taking the following steps:
> 
>       1. take the last 96 bits of the multicast address
> 
>       2. zero the last 128-"plen" bits, and
> 
>       3. replace the last 4 bits with the contents of "RPad".
> 
> 
> If "plen" is = 1 (say), which seems to be allowed, then how do I zero 
> the last 127 bits of a 96 bit slice of a multicast address ?
> 
> I am pretty sure this is not what you mean, but this is what I read it

> to say.

The first bullet makes it implicit that those 96 bits are placed at the 
beginning of a 128-bit address struct (which is assumed to have been 
initialized to zero).

But that should be clarified so there will be no misunderstandings, 
thanks.

> Regards
> Marshall Eubanks
> 
> 
> > Me and Brian Haberman have submitted a new draft to 
> > [email-masked]. In the interim, it's available at:
> > 
> > http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-mcast-rpaddr-0
> > 0.txt
> > 
> >          "Embedding the Address of RP in IPv6 Multicast Address"
> > 
> > Abstract                                               
> > 
> >    As has been noticed, there is exists a huge deployment problem
with
> >    global, interdomain IPv6 multicast: PIM RPs have no way of

> >    communicating the information about multicast sources to other
> >    multicast domains, as there is no MSDP, and the whole interdomain
Any
> >    Source Multicast model is rendered unusable; SSM avoids these

> >    problems.  This memo outlines a way to embed the address of the
RP in
> >    the multicast address, solving the interdomain multicast problem.
The
> >    problem is three-fold: specify an address format, adjust the

> >    operational procedures and configuration if necessary, and modify
> >    receiver-side PIM implementations.  In consequence, there would
be no
> >    need for interdomain MSDP.             
> > 
> > It's 9 pages.
> > 
> > Comments are welcome, either directly or to the list(s) if 
> > appropriate.
> > 
> > -- 
> > Pekka Savola                 "Tell me of difficulties surmounted,
> > Netcore Oy                   not those you stumble over and fall"
> > Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> > 
> > 
> > 
> > 
> > 
> > 
> 

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Brian Haberman <[email-masked]>
Date: Thu, 10 Oct 2002 20:36:47 -0400

Hi Lenny,

Leonard Giuliano wrote:
> 
> Going back a bit, if this ASM mechanism will rely on SSM-like group
> discovery, why not just use SSM in the first place?

I totally agree.  However, other people don't and they want ASM in v6.
I made it a point to ensure that we had a nice SSM range for v6 (see
RFC 3306).

What I would like to see with this work is whether or not we can have
ASM without the burden of MSDP.

If I had my way, SSM would be the solution even if we did have to deal
with N^2 state.  I would prefer that kind of problem. :)

Brian

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 10 Oct 2002 12:15:50 -0400

Marshall

-- 
                                  Regards
                                  Marshall Eubanks

This e-mail may contain confidential and proprietary information of
Multicast Technologies, Inc, subject to Non-Disclosure Agreements

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : [email-masked]
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
  Status of Multicast on the Web  :
  http://www.multicasttech.com/status/index.html

---

From: Bill Nickless <[email-masked]>
Date: Wed, 16 Oct 2002 13:27:06 -0500

At 02:36 PM 10/10/2002 -0700, Leonard Giuliano wrote:

>The main problem with SSM in IPv4 is that ASM was already in use, and
>there aren't enough implementations/deployments of SSM yet.  But v6 need
>not carry the same albatross of legacy mechanisms around it's neck.  It's
>a chance to do things right from the start.

IMHO, the biggest barrier to IPv4 SSM deployment is the requirement that 
edge IEEE 802 switches be re-engineered to understand a new kind of IP 
packet: the IPv4 IGMPv3 packet.

IPv6 suffers from the same problem; to wit, that IEEE 802 switches have to 
now be re-engineered to interpret IPv6 MLD packets.

Fix the unreasonable IGMPv3/MLD requirement for nominally IEEE 802 
switches, and I'll bet you dollars to donuts that SSM will take off like a 
rocket.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     [email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Oct 2002 21:31:50 +0300 (EEST)

On Wed, 16 Oct 2002, Bill Nickless wrote:
...
> now be re-engineered to interpret IPv6 MLD packets.

No: most switches by far work *just* fine.

Only if you want snooping features, or the switch uses a broken logic (see 
the issues draft) you have problems..
 
> switches, and I'll bet you dollars to donuts that SSM will take off like a 

Most switches work fine as is I believe, though flooding the multicasts
all over the segment.. yet where is SSM?  I sure would like to have it..

---

From: Bill Nickless <[email-masked]>
Date: Wed, 16 Oct 2002 13:36:25 -0500

>the issues draft) you have problems..

Well over a year ago we ran into situations where a normal Access Grid 
traffic would overrun a 10 megabit/sec switch port.  At the time the hosts 
were listening to RIP broadcasts to learn their default route.  The 
congestion on those 10 megabit/sec switch ports was *SO* bad that the hosts 
lost their RIP default route.

Darn right I want packets on a segment to only go to the appropriate output 
ports.  If I wanted a single collision domain I wouldn't buy a switch.

===

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Oct 2002 22:08:56 +0300 (EEST)

On Wed, 16 Oct 2002, ken lindahl wrote:
> that definition of working "fine" doesn't work for my campus. berkeley
> researchers are investigating the use of relatively high-bandwidth
> multicast (>10Mbps per stream) and i really don't want that flooding
> on departmental segments with one receiver. other Internet2-connected
> institutions are in similar positions, i think.

Smaller segments can be used if that's really a problem (100/FD should
probably handle some 20-30Mbit/s of multicast per port without anyone
noticing anything but I haven't tested).  

SSM <-> ASM reflectors (I dunno if these have been specified but should
not be difficult) could be used if that's really a problem.
 
> i agree with Bill's earlier comment: lack of IGMPv3 snooping in current
> switches is a major obstacle to IPv4 SSM deployment, and lack of MLD
> snooping will become an impediment to IPv6 SSM deployment.

There are many different kind of multicasts.  If SSM would be hitting big,
it would have come through with the other multicast applications (not so
high volume), but where is it now..?

I guess that's a good way to explain why SSM may be failing.

Sure, IGMPv3, MLDv2 snooping would be nice but it seems hypocritical to
say this is the reason why SSM isn't being used..

---

From: Bill Nickless <[email-masked]>
Date: Wed, 16 Oct 2002 14:26:37 -0500

>noticing anything but I haven't tested).

If I have to re-engineer a network, resegmenting and renumbering, just to 
support multicast (IPv4, IPv6, SSM, or ASM), then I'd better have a darn 
good business case to go to all that expense and complexity.

Taking your suggestion to an extreme, I would have to provide a layer-3 
routed port for every high-bandwidth multicast host.  Should I have to go 
to the trouble of assigning IPv4 /31s or /30s, or IPv6 /126es for every 
multicast-speaking host?  Sorry, it's just not going to happen.

IEEE 802 switches function just fine to send unicast frames only to the 
ports for which they're intended.  Unicast IP uses ARP/ND to discover the 
MAC addresses that the IEEE 802 switches depend on to make this 
happen.  What's wrong with asking IP multicast to use a similar mechanism?

===

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Oct 2002 22:48:03 +0300 (EEST)

On Wed, 16 Oct 2002, ken lindahl wrote:
> IGMPv2 snooping is enabled now on large parts of campus. i don't think
> IGMPv3 will play nicely with that. disabling IGMP snooping so that SSM
> will work doesn't seem like a step forward. where's the hypocracy in
> that?

Why would a switch with IGMP snooping enabled that doesn't understand a
word about IGMPv3 not handle IGMPv2 snooping properly even though SSM
multicast is broadcasted initally to every port in a segment with
receivers? (Note: most switches with IGMP snooping enabled forward IPv6 
multicasts just fine.)

If that's not possible, seems like a huge problem with IGMP (snooping):
either specification or implementation.

---

From: ken lindahl <[email-masked]>
Date: Wed, 16 Oct 2002 11:47:39 -0700

i sure would like to have SSM too...

ken

---

From: ken lindahl <[email-masked]>
Date: Wed, 16 Oct 2002 12:43:11 -0700

>noticing anything but I haven't tested).

umm. berkeley's campus network has approx 50,000 connected hosts on
approx 500 IP subnets. your suggestion sounds just a little bit expensive.
i'm guessing the campus doesn't want SSM _that_ badly.

ken

---

From: [email-masked]
Date: Thu, 17 Oct 2002 08:55:42 +0900

>will work doesn't seem like a step forward. where's the hypocracy in

	doesn't host compatibility mode behavior (draft-ietf-idmr-igmp-v3-11.txt
	7.2) help this situation?  caveat: i'm no multicast expert.

itojun

---

From: ken lindahl <[email-masked]>
Date: Wed, 16 Oct 2002 20:59:29 -0700

hi,

>        7.2) help this situation?  caveat: i'm no multicast expert.

and i'm no IGMP expert. but i think the answer is no: it won't help.
if the host(s) drop into v2 or v1 compatibility mode, they won't be
able to send (S,G) membership messages on which SSM depends. that
breaks SSM.

the real problem is the IGMPv2-snooping switch. the switch has to intercept
and process membership messages, that's an essential part of snooping.
if the switch is only v1 and v2 aware, it cannot send the appropriate
(S,G) membership message, so once again SSM is broken.

if, as was implicitly suggested earlier, the switch is somehow smart
enough (or dumb enough) to not recognize the v3 packets and simply
forwards them, then snooping won't work. and that's where i entered
this discussion: i consider snooping a requirement for my campus
network.

if someone who is an IGMP and multicast expert knows that i'm wrong,
i'd be glad to hear it.

ken

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 Oct 2002 08:24:07 -0400

> able to send (S,G) membership messages on which SSM depends. that

You are correct on this point.  Once the switch drops into one of
the compatibility modes, SSM is broke.  This applies to v4 and v6.

> (S,G) membership message, so once again SSM is broken.

Correct.

> this discussion: i consider snooping a requirement for my campus

A snooping switch is supposed to flood IGMP/MLD messages that it
does not recognize.  Most do, some don't.

> if someone who is an IGMP and multicast expert knows that i'm wrong,

You're not wrong.  The key is convincing switch vendors to support
IGMPv3 and MLDv2 snooping ASAP.  Tell your vendors you want/need
this functionality.  And tell them that you want them to implement
draft-ietf-magma-snoop-02.txt.

Regards,
Brian

---

From: Bill Nickless <[email-masked]>
Date: Thu, 17 Oct 2002 12:59:01 -0500

>draft-ietf-magma-snoop-02.txt.

What you just wrote is the orthodox view in the IP multicast community.

When I read that, I hear the IP multicast community saying:

"We developed this IP multicast thing before 802.11 switches 
existed.  MAC-based receiver registration isn't needed on 
single-collision-domain 10Base5 Ethernet segments, so we didn't bother with 
that when we developed the IP multicast protocols like IGMP.

"If the world is going to use 802.11 MAC-based switches, well then the 
802.11 MAC-based switches had better emulate a single-collision-domain 
segment, interpreting IPv4/IGMP and IPv6/MLD datagrams as necessary.  We're 
not going to change our way of doing things because we were here first."

===

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Oct 2002 14:24:37 -0400

> "We're not going to change our way of doing things because we were here first."

My view is that if a vendor sells products that have an Ethernet interface 
and claim to emulate an Ethernet, then they should actually emulate an 
Ethernet, at least by default.  Otherwise protocols and code that expect
the network to act like an Ethernet won't work.  That includes propagating 
broadcast and multicast packets to all stations.  If they can improve 
performance with clever snooping, fine, but that should always be optional.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 Oct 2002 14:48:52 -0400

Bill Nickless wrote:
> "We developed this IP multicast thing before 802.11 switches existed.  
> MAC-based receiver registration isn't needed on single-collision-domain 
> 10Base5 Ethernet segments, so we didn't bother with that when we 
> developed the IP multicast protocols like IGMP.
> 
> segment, interpreting IPv4/IGMP and IPv6/MLD datagrams as necessary.  
> We're not going to change our way of doing things because we were here 
> first."

Sounds to me like you just described a MAC-layer group management
protocol.  Since the IETF generally stays at Layer 3 (Sub-IP
excluded), it is out of our control.

Perhaps you should petition the IEEE to develop this protocol or
write a draft on how a layer 3 devices should advertise their
interest in receiving packets on layer 2 addresses.

Regards,
Brian

---

From: Bill Nickless <[email-masked]>
Date: Thu, 17 Oct 2002 14:11:12 -0500

>excluded), it is out of our control.

Exactly right.  So why are the IETF working groups like MAGMA trying to 
specify Layer 2 switch multicast behavior?

>interest in receiving packets on layer 2 addresses.

The IEEE 802.1p committee did develop a MAC-layer receiver interest 
protocol.  See the work on GARP/GMRP.  A good introduction to that work can 
be found in the second section of 
http://www.ieee802.org/1/mirror/8021/tobagi/garp-gmrp-timers.pdf .

I did write a draft, which included a discussion of how layer 3 devices 
should advertise their interest in receiving packets on layer 2 
addresses.  See the first part of section 22 (page 10) of

ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-iesg-gap-analysis-00.txt

It's written to first fix the truly unpatchable problem at multicast 
exchange points, where not all exchange point participants have peering 
agreements--leading to situations where datagrams might need to traverse 
the exchange point media more than once.  That happens all the time for 
unicast datagrams, but can't happen with multicast datagrams.  (Ibid, 
Section 20, page 8.)

Then, once the technology is tested and proven in the limited cases, 
leverage it at the network edge for large-ish segments (like at Berkeley).

===

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 Oct 2002 15:22:05 -0400

> specify Layer 2 switch multicast behavior?

Slow down, Bill.  MAGMA is not specifying how L-2 devices behave.
The snooping draft is guidance to switch vendors who want to do
IGMP/MLD snooping.  It is meant as an Informational document.
Nothing more.

> protocol.  See the work on GARP/GMRP.  A good introduction to that work 
> can be found in the second section of 

I will take a look at it.  Have you (or Ken) pushed on your router
vendors to support this in conjunction with the switch vendors?

> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-iesg-gap-analysis-00.txt

Ah, another draft I have on my list to read, but haven't gotten
to yet.  I will take a look at this also.

Brian

---

From: Bill Nickless <[email-masked]>
Date: Thu, 17 Oct 2002 15:33:32 -0500

>IGMP/MLD snooping.  It is meant as an Informational document.

I stand corrected on my terminology.  Let me try again.

So why are the IETF working groups like MAGMA trying to guide Layer 2 
switch multicast behavior?

>Have you (or Ken) pushed on your router vendors to support this in 
>conjunction with the switch vendors?

I can say that there's some adoption by switch vendors:

Cisco Systems already supports GARP/GMRP.  See, for example,
http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_guide_chapter09186a00800eb758.html

D-Link Systems claims future support for GARP/GMRP.
http://www.dlink.com/products/switches/des6000/

As of 2000 (at least), Cabletron/Enterasys supported GARP/GMRP.
http://www.cabletron.com/support/relnotes/rn_2806-06.html

Also, other areas of the IETF are aware of GARP/GMRP.  For example, RFC 
2878 (Standards Track) refers to GMRP support for the PPP Bridging Control 
Protocol (BCP).  http://www.ietf.org/rfc/rfc2878.txt

===

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 Oct 2002 17:34:35 -0400

> switch multicast behavior?

Um, because some switch vendors have asked for guidance.

> 2878 (Standards Track) refers to GMRP support for the PPP Bridging 
> Control Protocol (BCP).  http://www.ietf.org/rfc/rfc2878.txt

Cool.  That is a small step in the right direction.

Brian

---

From: Gert Doering <[email-masked]>
Date: Thu, 17 Oct 2002 23:56:30 +0200

Hi,

> interest in receiving packets on layer 2 addresses.

Which is something direly needed in "tightly meshed" ethernet switch
environments - some sort of "layer 2 SPF" protocol telling each 
bridge where what MAC address is connected, what the shortest path
to a given target is, and so on.

It's doable, but unless the market is willing to pay $$$$ for such 
devices, I doubt any vendor will invest the necessary money.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  48282  (47686)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: Havard Eidnes <[email-masked]>
Date: Tue, 22 Oct 2002 16:28:29 +0200 (CEST)

> i agree with Bill's earlier comment: lack of IGMPv3 snooping in
> current switches is a major obstacle to IPv4 SSM deployment, and
> lack of MLD snooping will become an impediment to IPv6 SSM
> deployment.

I've said it before and I'll say it again: it strikes me as
architecturally wrong to have traditionally cost-sensitive layer-2
switching devices having to implement interpretation of layer-3 protocol
information in frames not explicitly directed at itself.  It's IGMPv3
this day, and MLD for IPv6 the next day, and whatever we might dream up
next after that.  Multicast protocol development appears to still be in
flux.  This makes for complexity which leads to deployment problems
because old non-field-upgradeable devices need to be replaced and one
needs to wait for switch vendors to become aware of and then to
delivering software upgrades (even if the devices are field-
upgradeable).

It would seem to me to be an architecturally better and longer-term more
"stable" way to put the layer-3 smarts in the layer-3 devices, and to
devise a protocol where the layer-3 devices could direct the layer-2
devices as appropriate, a'la Cisco's CGMP.

Regards,

- Håvard